Hi Zoly, nice to meet you and thanks for your collaboration! Sorry to say that honestly I didn't understand where the optimization is - please take in consideration I woke up at 6am and at 10pm I'm still working, ehehe :P So I would appreciate if you can provide more details about your thoughts so we can reason about it. Many thanks in advance, have a nice day! Simo
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Wed, Feb 2, 2011 at 9:28 PM, zoly farkas <zolyfar...@yahoo.com> wrote: > Done: > > https://issues.apache.org/jira/browse/POOL-183 > > > > > ----- Original Message ---- > From: Phil Steitz <phil.ste...@gmail.com> > To: Commons Developers List <dev@commons.apache.org> > Sent: Wed, February 2, 2011 2:18:52 PM > Subject: Re: [pool] potential new method for interface ObjectPool<T> > > On 2/2/11 1:46 PM, zoly farkas wrote: >> Would it be possible to add a method: >> >> void returnAndValidateObject(T obj) throws Exception >> >> In general I was thinking of the following use case: >> >> Object o = pool.borrowObject(); >> try >> { >> ......... >> o.doStuff(); >> ......... >> pool.returnObject(o); >> } >> catch(Exception e) >> { >> // not sure what the cause is, let's make sure o is valid. >> pool.returnAndValidateObject(o); >> } >> >> the reason is that validation in general is an expensive operation, and >>enabling >> >> it all the time is inpractical. >> >> any thoughts ? > > Sounds like an interesting feature request, at least worth talking > about. Can you open a JIRA so we don't forget it? If you hold a > reference to the PoolableObjectFactory associated with the pool, you > can explicitly call the factory's validate method prior to returning > an instance to enable this behavior with the current implementation. > > Phil >> --Zoltan >> >> >> >> >> --------------------------------------------------------------------- >> 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
