When youit needis necessary to work with a large number of objects that are particularly expensive to instantiate and youeach onlyobject needis eachonly objectneeded for a short period of time, the performance of youran entire application may be adversely affected. InAn theseobject situationspool youdesign mightpattern may be abledeemed todesirable usein thecases objectsuch poolas design patternthese.
The object pool design pattern creates a set of objects that may be reused. When you need a new object youis requestneeded, it is requested from the pool. If a previously prepared object is available it is returned immediately, avoiding the instantiation cost. If no objects are present in the pool, a new item is created and returned. When youthe haveobject usedhas thebeen objectused and is no longer needneeded, it,youis return itreturned to the pool, allowing it to be used again in the future without going throughrepeating the slowcomputationally expensive instantiation process. It's is important to note that once an object ishas returnedbeen toused theand pool that you no longer use anyreturned, existing references. Doing so couldcausewill unpredictablebecome behaviourinvalid.
In some object pools the resources are limited so a maximum number of objects is specified. If this number is reached and a new item is requested, youan exception may electbe to throw an exceptionthrown, or block the thread will be blocked until an object is released back into the pool.
The object pool design pattern is used in several places in the standard classes of the .NET framework. One example is the .NET Framework Data Provider for SQL Server. As SQL Server database connections can be slow to create, a pool of connections is maintained. When you close a connection it does not actually relinquish the link to SQL Server. Instead, the connection is held in a pool from which it can be retrieved when requesting a new connection. This substantially increases the speed of making connections.
