[
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
