[
https://issues.apache.org/jira/browse/IBATIS-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491675
]
Cesar Orosco commented on IBATIS-249:
-------------------------------------
Hi, we have a enviroment in websphere, Ibatis and DB2 we are currently work
with ibatis 2.2.0 but we have a thread problem like this reported previously :
"The application works fine for several thousand database calls through iBatis.
After a while, suddenly it hangs whenever it is tries to access the database
through iBatis."
Initally we have Ibatis 2.0.8 but we are update to 2.2.0 and the issue continue.
¿if we setting the maxWait parameter in Throttle.java "public Throttle(int
limit, long maxWait)" this could to solve the problem?
Any Idea?
Thanks
P.D. I apologize for my language! ;)
> Race conditions in Throttle lead to thread blockage popping items from
> ThrottledPools under stress
> --------------------------------------------------------------------------------------------------
>
> Key: IBATIS-249
> URL: https://issues.apache.org/jira/browse/IBATIS-249
> Project: iBatis for Java
> Issue Type: Bug
> Components: SQL Maps
> Affects Versions: 2.1.7
> Reporter: Jonathan Burstein
> Assigned To: Sven Boden
> Fix For: 2.2.0
>
> Attachments: IBATIS-249.diff
>
>
> com.ibatis.common.util.Throttle.increment contains a synchronization error.
> Currently, when a waiting thread returns from LOCK.wait it will increment
> count and return without checking that count is below limit. There are a
> number of situations where LOCK.wait can complete but the count will not be
> less than the limit:
> 1) The wait was interrupted
> 2) There was a spurious thread wakeup
> 3) Another thread obtained the lock between the time LOCK.notify was called
> (by a thread calling decrement) and the wait returned.
> The fix here is to re-check the value of count after exiting the wait (using
> a while loop). A small amount of extra logic is necessary to satisfy maxWait
> properly.
> ThrottledPool.pop attempts to work around these race conditions by catching
> swallowing all exceptions from throttle.increment and pool.remove(0) and
> looping until an item is obtained. Since the increment call is within the
> loop this logic can lead to multiple increments with no corresponding
> decrements. Note that an IndexOutOfBound exception from pool.remove(0) is an
> artifact of the bug in Throttle.increment -- this could never occur if
> Throttle behaved correctly.
> This routine should simple call throttle.increment and pool.remove(0). It
> should most certainly not swallow exceptions.
> Finally, ThrottledPool.push incorrectly calls throttle.decrement if the
> parameter is invalid (null or of an incorrect type).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
