commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Thomas (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (POOL-84) [PATCH] Proposal for a new pool type SharedObjectPool
Date Sat, 11 Jun 2011 20:39:58 GMT

     [ https://issues.apache.org/jira/browse/POOL-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mark Thomas updated POOL-84:
----------------------------

    Comment: was deleted

(was: Test comment. Please ignore. (I'll delete it shortly). Apologies for the
noise on the list.





)

> [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
>             Fix For: 2.0
>
>         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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message