When does a connection pool gets cleared?

The mongodb documentation states that connectionPoolCleared is “Created when a connection pool is cleared”.
My question is that when does a connection pool is cleared?

Documentation also states that If socketTimeoutMS is set to n milliseconds, it means that Mongodb driver will close sockets if they are inactive more than n milliseconds.

Does this mean that if all the connections(sockets) in a connection pool timeout, then this event is emitted?
Are there any other cases in which this event is emitted?

Hello @Sadegh_Hosseini ,

Welcome to The MongoDB Community Forums! :wave:

Connection Pool’s primary benefit is to have ready-to-use database connections which helps reduce application latency and the number of times new connections are created.

There can be many cases when a connection pool is cleared such as:

  • When the application or server shuts down or restarts.
  • When the connections in the pool are closed due to errors, timeouts, or network issues.

It could be one of the reason but mostly MongoDB instances try to have a cache of open, ready-to-use database connections maintained by the driver. You can actually specify the min and max pool size in your MongoDB URI. Please refer to the Connection Pool Configuration Settings documentation.

Can you please share your requirements to help me understand your use-case in more detail? Specifically, do you want to clear the connection pool, or do you have any other requirements?


1 Like

Thanks for answering.
I am using Nodejs and Mongoose.
For a “Database per tenant” multitenancy approach. There are two solutions:

  1. creating a connection and using "[Connection.prototype.useDb()]
  2. creating a connection pool per tenant and caching the connection objects on a javascript map

In order to implement the 2nd approach, I was thinking it would be best if there was a way to remove the connection objects of tenants(who have been inactive for certain amount of time) from the connection cache.

Of course it is possible to keep records of tenant’s most recent activity time and schedule a task for this. But I think it would be easier if there were some event which got emitted by nodejs mongodb drive whenever all the connections in a connection pool timed out, that I could listen to and remove the connection object from the connection cache.

All official MongoDB drivers create a connection pool, and the individual connections inside the pool are automatically managed by the driver themselves using typically a MongoClient object. This object is expected to last for the lifetime of the application. This is done to help and make things easy so that developers do not need to worry about managing the connections along with other things and it also helps in reducing application latency. You can take a look at Create and Use a Connection Pool for more information.

You can tune your connection pool settings as most users try to adjust minPoolSize or maxPoolSize as per their application requirements and resources available. You can also take a look at Tuning Your Connection Pool Settings for more information regarding this. To learn about connection and authentication options supported by the Node.js driver please visit MongoDB connection and authentication options.

Lastly, please refer below link in case you are interested in implementing Multi-Tenant Architecture for your application in MongoDB Atlas

From the view point of “connection management in MongoClient”, it doesn’t (and shouldn’t) care how many databases will be used by this application or which one has more/less traffic. They are just treated equivalently during connection management. The connection is just a virtual tcp connection between your driver and the other party (be it a mongodb server or mongos or similar).

Whenever you need a connection to read-from/write-to the mongodb deployment, the driver helps you to find one from the pool if any is available.

So in a nutshell, mongo drivers will manage then in a mostly transparent way, and generally you can just rely on it.