Object pool pattern: Difference between revisions

Revision as of 08:32, 7 October 2005

Revision as of 08:44, 7 October 2005

Line 1:

In [[computer programming]], an '''object pool''' is a construct of objects which can be used concurrently. Typically, ana client object which requires resources which are managed by the object pool will request an object from the pool and perform operations on thatthe returned object. Object pooling offers a significant performance boost and is most efficient in situations where the cost of initializing a class instance is high and the amount of instantiations of a particular class is also frequent.

If no objects are available in the pool, a new object is created and returned to the pool when it hasis beenno dereferencedlonger referenced (it's no longer being used). This allows for control of resources and limits the amount of work necessary to instantiate and initialize new objects. The object pool will release objects within the pool when requests for objects diminishes.

This contruct is typically employed in software in situations where instantiating an object is prohibitively expensive, or the object itself uses a significant amount of resources and must be controlled in a fixed pool size.

When writing an object pool, the programmer has to be careful to make sure the state of the objects returned to the pool is reset back to a useable state for the next use of the object. Often if this is not observed, the object will be in some state that was unexpected by the client program and that will cause the client program to fail.

<!--

If objects within the pool contain state which is only set to initial conditions at construction, it is possible to end up with an [[object cesspool]]. This occurs when objects in the pool contain stale state from previous usage, which should have been reset before the object was handed to the client. -->

The presence of stale state is not always an issue; it becomes dangerous when the presence of stale state causes the object to behave differently. For example, an object that represents authentication details may break if the "successfully authenticated" flag is not reset before it is passed out; however, it will work just fine if you fail to reset the identity of the last authentication server used. Generally, this problem is avoided by amending the objects in the pool to include a "reset state" method, which is called just before the object is handed out and which resets any dangerous state to the construction defaults.