On 12/12/11 12:29 PM, Simone Tripodi wrote: > Hi Phil, > thanks for the feedbacks! I would put some energies on [pool2] since I > am currently in the situation I need it - of course in the meantime I > can work with snapshots, but having a release would be definitively > better :) > > So I start filling an issue and update synchronized pools in > PoolUtils, then IMHO we should back speaking about implementing > Read/Write policy in Pools implementation. Thoughts?
Personally, I think the 2.0 implementations in GKOP and GOP are good and would prefer to focus on making the final preparations for release rather than reworking the - very tricky - locking and synchronization semantics in those implementations. That said, if you or anyone else has better ideas, we can certainly look at them. Performance and intensive concurrency testing of the code in trunk would also be very helpful. Phil > > -Simo > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > > > On Mon, Dec 12, 2011 at 7:21 PM, Phil Steitz <phil.ste...@gmail.com> wrote: >> On 12/12/11 10:56 AM, Phil Steitz wrote: >>> On 12/12/11 10:26 AM, Simone Tripodi wrote: >>>> Hi all guys, >>>> time ago we spoke about replacing the synchronized blocks inside >>>> pools, maybe using different strategies like Java5 Read/Write lock (I >>>> remind you Pool2 requires Java5) and I just started playing with >>>> PoolUtils with the SynchronizedObjectPool[1] inner class... >>>> Can we discuss about introducing such modifications inside pool >>>> implementations? >>> I would say go for it in PoolUtils. Assuming we keep these pools, >>> we should update them as we have GOP, GKOP. Regarding the pool you >>> mention specifically, it is a little funny in that it is designed to >>> be fully synchronized. Make sure that whatever implementation >>> changes you propose maintain the contract. >> Looking at the github code, I think there may be a problem. Borrow >> is as much a "write" operation as return - both modify the state of >> the pool. >> >> Phil >>> Phil >>>> Many thanks in advance, all the best! >>>> -Simo >>>> >>>> [1] https://gist.github.com/1468252 >>>> >>>> http://people.apache.org/~simonetripodi/ >>>> http://simonetripodi.livejournal.com/ >>>> http://twitter.com/simonetripodi >>>> http://www.99soft.org/ >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
