A Theorical Look into Object/Resource Pool Pattern
Join the DZone community and get the full member experience.
Join For Free- Reuses unused costly objects without re-creating those objects (e.g. books in a library).
- May create objects eagerly before they are needed, to manage application performance.
- May limit created number of objects to manage application performance and user access.
- If memory is limited and/or maximum number of clients are needed to be restricted, an object number limit value may be defined for object pool (limited pool).
- If there is no restriction, limit value is not needed (unlimited pool).
- If all object pool list is in use, new objects may be created (expanding pool) or client may be enforced to waiting (fixed pool).
- If application startup is performed infrequently and startup time is not very important, object pool list objects may be created at the startup (eager ceration).
- If no restrictions exist, no objects are needed to be created eagerly (lazy creation).
- Some number of objects may be created eagerly, others may be created lazily according to the application parameters (mixed creation).
- If object pool is expanding, create a new object and return it.
- If object pool is not expanding, return null or enforce client to wait until an object is ready to be given.
- Object pool should have a synchronization mechanism for object serving. Otherwise, especially on multiuser systems, pooling system may fail.
- Usage of the pool objects may be lower than expected in some cases. Object pool may have a pool object removing strategy (i.e. descreasing object limit) for increasing performance.
- Clients should return pool objects back to the pool after their job is completed. But pool code can't control this and poor client code may return pool objects. For this situation, object pool may have a timer mechanism for given but unused pool objects.
Published at DZone with permission of Cagdas Basaraner, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments