commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <>
Subject [jira] Commented: (POOL-104) Incorrect behavior for returnObject function.
Date Wed, 01 Apr 2009 17:30:13 GMT


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:
>             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.

View raw message