[ https://issues.apache.org/jira/browse/POOL-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sebb closed POOL-84. -------------------- Resolution: Won't Fix > [PATCH] Proposal for a new pool type SharedObjectPool > ----------------------------------------------------- > > Key: POOL-84 > URL: https://issues.apache.org/jira/browse/POOL-84 > Project: Commons Pool > Issue Type: New Feature > Affects Versions: 1.3 > Reporter: Mariusz Krzemien > Attachments: sharedobjectpool-patch.zip > > > 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). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira