[
https://issues.apache.org/jira/browse/POOL-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694628#action_12694628
]
Sebb commented on POOL-104:
---------------------------
I've not looked at the code, but it should be possible to keep track of objects
by storing the thread-id against the object id when an item is borrowed, and
clearing it when it is returned.
This would also allow one to check whether an Object is being shared between
threads - is it being released by the same thread?
It could perhaps help in tracking down resource leaks.
The solution would require extra storage and processing, so it should be
optional.
One way might be to use a pool decorator to implement it.
==
Another possibility might be to define an interface - e.g. "Ownable" - which
gives access to the owner information.
Commons Pool could provide a decorator class that used the Ownable interface.
However this would require applications to implement Ownable in the Objects
they want to use, or write a wrapper that implements it.
Not sure this second option would be worth the effort for Commons Pool, but it
might be a workable solution in particular applications.
Just my 2p.
> Incorrect behavior for returnObject function.
> ---------------------------------------------
>
> Key: POOL-104
> URL: https://issues.apache.org/jira/browse/POOL-104
> Project: Commons Pool
> Issue Type: Improvement
> Affects Versions: 1.3
> Environment: Windows XP + Eclipse3.2 + JDK1.5
> Reporter: Phenix Huang
> Fix For: 3.0
>
>
> Bussiness Needs
> I want to implement a special pool which can restore the active item
> automatically after over time. After the item had been restored by the pool,
> if client still return the object to pool(client still keep the reference
> thought the object had been passative) , the issue will occurs.
> Test Case :
> 1. Client borrow an object from pool.
> 2. Client return the object to the pool. The active num will substract 1 and
> idle num will plus 1.
> 3. If the client return the same object to the pool many times, the active
> num might be negative.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
