Connection pooling enables your .NET application to recycle a connection a pool of connections that have been previously closed. Once a connection with a particular connection string has been created it is placed in a pool during the Close() operator and an application can then reuse that connection without the expense of rebuilding the entire object. When the application requests a connection an existing object is returned from the set of pooled connections. When the object is closed again it will be added back to the pool for reuse.
This can have a substantial, positive impact on the performance of your application. When a new connection is built VistaDB must open the database, validate the headers of the file, check to make sure the version of the database is the same as the engine, etc. In other words a lot of housekeeping happens when you first build a connection.
Connection pooling may be enabled by setting the "Pooling=true" keypair in your connection string. The default minimum pool size is 5, and the maximum is 50.
Connection pooling should not be used with EXCLUSIVE modes. This can lead to difficult to debug issues within your application.
Keep in mind the sequence of events for connection pool may be out of order if you do not put using statements in your code. Look at the following example:
- Connection1 opens exclusive to the database. And is then closed.
- POOL1 is now assigned the connection.
- Connection2 opens database using same connections settings and is given POOL1. POOL1 is now empty. Connection2 calls close in the finalizer for the class and is non-deterministic.
- Connection3 opens database using same connections and fails because Connection2 is still open.
In general connections should be treated either as a global that you lock and manage yourself, or opened with using statements and torn down as quickly as possible.
Connection pool settings may be set in the connection string, or through the properties of the VistaDBConnectionStringBuilder. See this topic for more information.