ReactiveMongo: single connection pool instance Vs

Question

I am using ReactiveMongo 0.12, and trying to understand the core differences between how different types of connection pooling works in ReactiveMongo.

ReactiveMongo seems to provide 3 ways in which we can establish connection with the database:

TYPE 1: Using Single Connection Pool Instance

import reactivemongo.api.MongoConnection
val driver1 = new reactivemongo.api.MongoDriver
val connection3 = driver1.connection(List("addressA: 27017", "addressB: 27017","addressC": 27017", "addressD: 27017"))

TYPE 2: Using multiple Connection Pool Instances

import reactivemongo.api.MongoConnection
val driver1 = new reactivemongo.api.MongoDriver
val connection1 = driver1.connection(List("addressA", "addressB"))
val connection2 = driver1.connection(List("addressC", "addressD"))

TYPE 3: Using multiple connection pools

import reactivemongo.api.MongoConnection
val driver1 = new reactivemongo.api.MongoDriver // first pool
  val driver2 = new reactivemongo.api.MongoDriver // second pool

  // Pick a connection from the first pool
  def connection1 = driver1.connection(List("addressA", "addressB"))

  // Pick a connection from the second pool
  def connection2 = driver2.connection(List("addressC", "addressD"))

What are the differences between these 3 types of connection ? Which would be the best approach in terms of performance?

Answer 1

As indicated in the documentation, on one side there are the heavyweight types MongoDriver and MongoConnection (heavy meaning they are managing many resources, as network channels).

As it can be read in the documentation, "MongoDriver holds the actor system" (Akka as implementation details : "the driver creates a new actor system") while "MongoConnection the references to the actors" managing the connection pool ("creating network channels").

On the other hand as mentioned, "DefaultDB and Collection are just plain objects that store references and nothing else. Getting such references is lightweight".

• So case 1 is using a single ActorSystem (which as memory and CPU cost), and a single connection pool.
• The case 2 differs from the first one as it defines 2 connection pools, which could only make sense if using different nodes (ReplicaSet), or the same nodes with different connection options.
• Finally case 3 differs from the second one using multiple drivers, and so multiple ActorSystem, which make quite no sense (except in very specific case, e.g. for testing).