commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mariusz Krzemien (JIRA)" <j...@apache.org>
Subject [jira] Created: (POOL-84) [PATCH] Proposal for a new pool type SharedObjectPool
Date Sun, 01 Oct 2006 11:28:19 GMT
[PATCH] Proposal for a new pool type SharedObjectPool
-----------------------------------------------------

                 Key: POOL-84
                 URL: http://issues.apache.org/jira/browse/POOL-84
             Project: Commons Pool
          Issue Type: New Feature
    Affects Versions: 1.3
            Reporter: Mariusz Krzemien


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 contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message