Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Won't Fix
-
1.3
-
None
-
None
Description
SharedObjectPool is a pool with additional feature of sharing pooled objects among many clients. Such pool is applicable for any resource that can be shared by multiple clients in the same time. The JMS Connection (which can be shared among many MessageConsumers in the same time) is an example of such resource.
Existing pools don't provide such functionality. Object can either be borrowed (exclusively accessed by just single client and out of control of the pool) or returned in the pool (where it is always treated as idle and so e.g. may be evicted at any time)
The SharedObjectPool interface introduced here is a proposition for a solution. The borrowed object gets associated with the borrowing client. It may be returned to the pool but still remain associated with the client. The object may then be borrowed by this client again. It may be also borrowed by some other clients in case (depending on the policy of actual implementation) the pool decides that borrowing an object with already associated client is preferable to returning a new or idle one.
I tried to be as compliant as possible with the existing structure of the Commons Pool types. Because there is a key parameter in main methods (that is used to associate the client with the pooled object) in my proposition the SharedObjectPool extends the KeyedObjectPool. It may equally be changed to a separate pool type since there are some incompatibilities (addObject(key) has no meaning for SharedObjectPool, so I had to add addObject() to the interface; also the existing tests assume that the KeyedObjectPool instance allows for multiple objects for the same key which is not true for SharedObjectPool).
The patch contains one implementation GenericSharedObjectPool - which is in fact the GenericObjectPool extended for purposes of object sharing.
There are also classes from the org.apache.commons.collections package - they are used by the GenericSharedObjectPool as a part of the implementation. I had to attach these classes here since they are not yet a part of the Commons Collections distribution - I contributed them in a separate patch proposal: https://issues.apache.org/jira/browse/COLLECTIONS-224. These classes in turn depend on the Commons Collections distribution.
Following main classes are attached in this patch:
SharedObjectPool - general interface
BaseSharedObjectPool - base (mostly stubbed) implementation
GenericSharedObjectPool - actual implementation with the policy that in case the number of created objects reaches declared maximum, if a client requests borrowing an object it is returned with an already shared object with possibly the least number of associated clients from the objects actually available in the pool (not borrowed by any client - borrowing the object is the way of blocking it for access from any other client).