commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [POOL] you can return your object several times?
Date Wed, 04 Jun 2008 10:41:30 GMT
On 04/06/2008, Mark Thomas <markt@apache.org> wrote:
>
>  sebb wrote:
>
> > On 03/06/2008, Mark Thomas <markt@apache.org> wrote:
> >
> > >  kpetrov wrote:
> > >
> > >
> > > >
> > > >
> > > > Mark Thomas-18 wrote:
> > > >
> > > >
> > > > > kpetrov wrote:
> > > > >
> > > > >
> > > > > > I tested a simple scenario where I return the same object several
> > > > > >
> > > > >
> > > >
> > > times:
> > >
> > > >
> > > > > Which version of pool are you using?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > 1.4. Actually, just checked the source code...seems like this is done
> by
> > > > design... was surprised though.
> > > >
> > > >
> > >
> >
> > So long as it is documented, it seems reasonable to me.
> >
>  I may not be understanding the code correctly but it looks like only
> GenericObjectPool has a warning on returnObject() but other implementations
> have the same contract but no warning. A patch that updated the JavaDocs
> wouldn't hurt.
>
>
> > For example, some close() methods can be called multiple times; only
> > the first close() needs to do anything, later calls to close() are
> > ignored. This can be useful in cleanup code.
> >
>  I should look at the code some more. I am wondering what happens when
> threadA calls close() (which in turn calls returnObject()) , threadB calls
> borrowObject() and gets the object just returned by threadA and whilst
> threadB is using the object threadA calls close() again.
>
>
> >
> > >  I haven't looked at the code in a while so I don't know how easy it
> would
> > > be to patch this. If you were able to suggest a patch I am sure it would
> be
> > > welcomed (create a JIRA issue and attach it there).
> > >
> >
> > I don't think the behaviour should be changed unless it is clearly not
> intended.
> > And even then, unless it causes a problem, why risk breaking
> > applications that rely on it?
> >
>  I can't think of any use cases where having the same object in the pool
> more than once is anything other than a bug. I would be interested in any
> use case you have that relies on this behaviour.

Nor can I, and the code should not allow that to happen.
It should either treat the second call as a noop, or throw an exception.

But allowing the application to returnObject() more than once may
perhaps be useful, as in the close() analogy.

>  The complexity of the code necessary to enforce the contract stated in the
> Javadocs would have to be weighed against the benefits of explicitly
> enforcing the contract. I can see some benefit in doing this but until there
> is an actual patch to consider...
>
>
>  Mark
>
>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail:
> user-unsubscribe@commons.apache.org
>  For additional commands, e-mail: user-help@commons.apache.org
>
>

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


Mime
View raw message