[jboss-jira] [JBoss JIRA] Commented: (JBAS-3992) Race condition in JBossManagedConnectionFactory

[Derek Lewis (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBAS-3992?page=comments#action_12350978 ] 
            
Derek Lewis commented on JBAS-3992:
-----------------------------------

So, when a pool is in the process of being flushed (not shutdown, just flushed), it's expected behavior for it to fail to return connections?  It does successfully return connections on the next call, so it seems very odd to me that it would be expected behavior for it to just throw exceptions for a brief moment.

> Race condition in JBossManagedConnectionFactory
> -----------------------------------------------
>
>                 Key: JBAS-3992
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3992
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: I'm running JBoss 4.0.4.GA on jaba 1.5.0_07-b03.
> I haven't tried a newer JBoss, however the code I've determined is causing the
> problem looks the same on 5.0.0.Beta1.
>            Reporter: Derek Lewis
>         Assigned To: Weston Price
>
> The problem happens when calling flush() on JBossManagedConnectionPool via the jmx-console.
> If a call to getConnection() is made by the application at the same time, there is a potential for getConnection() to throw a  ResourceException saying "The pool has been shutdown".
> Thread 1: calls flush()
> Thread 2: calls getConnection()
> In Thread 1, in JBossManagedConnectionPool.flush(), after the pools are iterated through and shut down (this is synchronized on subPools).
> Assume that a context switch happens here, and Thread 2 runs now, with Thread 1 paused, before calling subPools.clear().
> When thread 2 gets to where it calls getSubPool(...), this is not synchronized, so subPools.get(key) returns a pool which is not null  though it has been shutdown), and returns it.
> getConnection() is then called on this pool, causing the exception to be thrown.
> Thread 1 then proceeds to clear the pool, so that the shutdown subpools are not returned.  (But it's too late for this one case)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira