The Spring.Pool namespace contains a generic API for implementing pools of objects. Object pooling is a well known technique to minimize the creation of objects that can take a significant amount of time. Common examples are to create a pool of database connections such that each request to the database can reuse an existing connection instead of creating one per client request. Threads are also another common candidate for pooling in order to increase responsiveness of an application to multiple concurrent client requests.

.NET contains support for object pooling in these common scenarios. Support for database connection pools is directly supported by ADO.NET data providers as a configuration option. Similarly, thread pooling is supported via the System.ThreadPool class. Support for pooling of other objects can be done using the CLR managed API to COM+ found in the System.EnterpriseServices namespace.

Despite this built-in support there are scenarios where you would like to use alternative pool implementations. This may be because the default implementations, such as System.ThreadPool, do not meet your requirements. (For a discussion on advanced ThreadPool usage see Smart Thread Pool by Ami Bar.) Alternatively, you may want to pool classes that do not inherit from System.EnterpriseServices.ServicedComponent. Instead of making changes to the object model to meet this inheritance requirement, Spring .NET provides similar support for pooling, but for any object, by using AOP proxies and a generic pool API for managing object instances.

Note, that if you are concerned only with applying pooling to an existing object, the pooling APIs discussed here are not very important. Instead the use and configuration of Spring.Aop.Target.SimplePoolTargetSource is more relevant. Pooling of objects can either be done Programatically or through the XML configuration of the Spring .NET container. Attribute support for pooling, similar to the ServicedComponent approach, will be available in a future release of Spring.NET.

Chapter 37, IoC Quickstarts contains an example that shows the use of the pooling API independent of AOP functionality.

The Spring.Pool namespace provides two simple interfaces to manage pools of objects. The first interface, IObjectPool describes how to take and put back an object from the pool. The second interface IPoolableObjectFactory is meant to be used in conjunction with implementations of the IObjectPool to provide guidance in calling various lifecycle events on the objects managed by the pool. These interfaces are based on the Jakarta Commons Pool API. Spring.Pool.Support.SimplePool is a default implementation of IObjectPool and Spring.Aop.Target.SimplePoolTargetSource is the implementation of IPoolableObjectFactory for use with AOP. The current goal of the Spring.Pool namespace is not to provide a one-for-one replacement of the Jakarta Commons Pool API, but rather to support basic object pooling needs for common AOP scenarios. Consequently, other interfaces and base classes available in the Jakarta package are not available.