On 10/05/2011 16:48, ma...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to