sebb wrote:
On 04/06/2008, Mark Thomas <[EMAIL PROTECTED]> wrote:
sebb wrote:
On 03/06/2008, Mark Thomas <[EMAIL PROTECTED]> 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...
The practical problem here is that you would need to fully search the
pool on each returnObject. This could cause performance problems and
would be tricky to do safely. Also, I need some convincing that it is a
good idea for the pool to make any commitments regarding client
references to objects that have been returned - i.e., allowing clients
to continue to hold and meaningfully use these references (which
returning them twice basically gets into).
I assume also that reference equality, not equals would be used to
compare; otherwise some legitimate use cases could break.
If this behavior is really important to client applications, it is
probably better on the client side to wrap the pooled objects in an
adaptor that makes "close" or "return" idempotent, which is what DBCP
does (in trunk repeated close is now allowed).
Phil
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
