commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: svn commit: r1101516 - in /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl: GenericObjectPool.java PooledObject.java PooledObjectState.java
Date Tue, 10 May 2011 16:00:48 GMT
On 10/05/2011 16:48, markt@apache.org wrote:
> Author: markt
> Date: Tue May 10 15:48:22 2011
> New Revision: 1101516
> 
> URL: http://svn.apache.org/viewvc?rev=1101516&view=rev
> Log:
> Move to using LinkedBlockingDeque for the queue of idle objects.

This is probably a good point to (try and) explain what I have in mind
for pool2.

First the high-level plan:
- re-write GOP to use java.util.concurrent (it is simpler than GKOP)
- re-write GKOP based on GOP changes
- optionally (depending on performance) re-write GOP as a special case
(single key) of GKOP

The plan for the GOP re-write:
- based around LinkedBlockingDeque
- state is maintained in PooledObject (replaces ObjectTimestampPair)
- state changes are synchronized but only for that instance of PooledObject
- I have a tentative state transition diagram. It is a pain to represent
in ASCII art so I will add it to the Javadocs once it is closer to being
final
- object counts will be maintained using atomics (or possibly a custom
class depending on synchronization requirements)
- there should be no other synchronization

I'll be committing as often as I can get the code to pass the unit
tests. Right now, I don't know if that means a few commits or a lot of
commits.

I am sure that as I commit these changes, folks will spot holes in the
logic. Please point them out. It would be a huge help if you could
provide a unit test that demonstrates the problem.

Mark



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


Mime
View raw message