With the Q3 2011 release of Telerik OpenAccess ORM we introduced three connection pool type settings. The OpenAccess Connection Pool, OpenAccess Connection Pool with OpenAccess Connection Management and the ADO Connection Pool. This blog post will show how these types can be used and when it makes sense to make use of them.
OpenAccess Connection Pool
With the type set to OpenAccess Connection pool, Telerik OpenAccess ORM will handle the connection pooling internally. Therefore a set of ADO connections is created that are maintained by the product. All settings for the connection pooling behavior can be configured via the settings dialog or in the BackendConfiguration. The connections maintained in the internal pool are used for all contexts. To not get in conflict with the underlying driver, the connection pooling of the driver will be disabled by setting the Pooling property to false. When using this type of connection pooling, we are able to use features like ‘Test on Allocation’ where the connection is tested each time it is leaving the connection pool or specifying the size of the connection pool with the ‘Maximum Idle Connections’ setting. See the documentation for more details about these settings.
This type of connection pooling is used in most scenarios.
OpenAccess Connection Pool with OpenAccess Connection Management
When we choose this connection pool type, we will basically use a plain ADO connection that is maintained by the underlying driver. The connections created this way, are not maintained by the Telerik OpenAccess ORM connection pool, meaning that the connection is returned to the diver connection pool after it was used. But Telerik OpenAccess ORM provides us with some management features that can become quite useful like the ‘Maximum Connections Used’ setting with which you could set the maximum number of connections to be used or the ‘Key Gen Reserved Connections’ setting which prevents deadlocks on commit operations by having separate connection only for the primary key generation.
This type of connection pool is useful when we want to use impersonation for our connections. Therefore the underlying driver must support the usage of impersonation.
ADO Connection Pool
When this type of connection pool behavior is set, we are using the plain Ado driver. We can configure everything with our connection string, but we don’t have any features that are provided by Telerik OpenAccess ORM, like the ‘Maximum Connections Used’ setting.
In this mode we don’t do any modifications to the connection string except for SqlServer where we add a “MultipleActiveResultSets=true;” because this setting is needed for improved fetching operations on referenced collections.
With the Q3 2011 release of Telerik OpenAccess ORM we have the full flexibility of how we connect to the database.