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? -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
