[jboss-dev-forums] [Design of JCA on JBoss] - Re: [JBAS-5095] Race condition between connection.close() an

[adrian@jboss.org]

There's no need for a reentrant lock, a plain synchronize would do.
This code cannot recurse and fair queuing is irrelevant.

The returnManagedConnection() needs to be outside the lock,
otherwise you'll get all sorts of deadlocks with other locks, e.g. the permits in the pool.

The ConnectionManager should not be locking anything when it invokes the pool
(there's all sorts of bizarre paths/callbacks between the pool and CM).

if the fix was as simple as this patch, then I'd have done it rather than
introducing the workaround. :-)

The fix is to replace isManagedConnectionFree() with wasManagedConnectionFreed().
i.e. the managed connection might now be free, but it wasn't us that freed it
=> do it only once

Most of the fix, is not the patch, it is some stress testing to make sure there's no hole
in the logic, e..g connection leaks, double release, etc.

Not just when racing with transaction timeouts, but also with "random"
connection failures leading to destroing of connections, 
both from application calls and pool calls.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166394#4166394

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166394