Note: This is the first post in a series about an object pooling pattern. You can follow along with code in this repo on Github. The repo will be steps ahead of this series, so don’t worry if there’s things in there I haven’t explained.
- Real world examples
- Components of a pool
An Object pool is a pattern used to maintain a pool of objects (natch) that is useful in situations where initialization of those objects is expensive, such as database connections or network connections in general.
Real world examples⌗
When a new
SqlConnection is opened, a connection pool is either created or used based on the connection string. This also involves pool “groups”, which is how the pool-per-connection string is managed, but is out of the scope of this series.
Ldaptive is a Java LDAP connection library. Most of the concepts in this series will be adapted from Ldaptive, as it’s an accessible but robust pool implementation.
Components of a pool⌗
The object pool is the main mechanism for maintaining the objects. It handles scaling up or down, delegation of the creation of new objects, and acts as traffic cop to hold requests for a bit when no new connections are available.
The object is the thing requiring pooling. We expect this to implement
IDisposable, as most objects needing pooling contain unmanaged resources. Even if it doesn’t, we’ll show in a later post how to create a class that does implement
IDisposable to be usable in our pool.
The proxy wraps the object and mainly tracks the lifecycle of the object in the pool and intercepts calls to
Dispose() to return the object to the pool. This will be explained in the next post.
The factory is responsible for actually creating the object, as the pool does not know how to actually construct its members.
This post hopefully gave a good intro into the why and what of pooling mechanisms. In the next post, we’ll go more in depth into the proxy, including talking about dynamic proxies and introducing Dyanmic Proxy from the Castle Project.