"jhalliday" wrote : yes, blocking end() should eliminate the race, at the cost of the rollback no longer actually 'killing' a long running operation. | Ok that's what I'm doing. Maybe I should change the try-lock to have a default value. Blocking forever is never a good idea. anonymous wrote : | My concern with actually interrupting the business logic operation is related to the way connections are multiplexed. You may have one or more logical connections on a single TCP/IP connection. Killing the network level one may therefore kill unrelated business operations in other threads. Depending how the multiplexing is implemented by the driver, interrupting a logical connection handle may mess up the multiplexing, with much the same undesirable side effects. Potentially you have to throw away the entire connection pool, not just a single logical connection if you want to be safe. | No , I'm talking about doing ManagedConnection.destroy() effectively invoke close() on all the physical connections that are part of the timed out transaction and where the connection-factory has been configured for this behaviour due to known or suspected broken/hanging drivers. Whether the underlying driver actually honours the request or is mulitplexing underneath is another question. It's just further option to try to recover from broken/blocking connections causing timeouts. Whether you also interrupt() the thread is a different issue, since in most cases a close() - MSSQL aside - should be allowed to proceed even with other concurrent requests. anonymous wrote : | Add to that the fact that the XA control messages probably flow over the same TCP/IP connection and you wind up with a problem. Sure, presumed rollback means that the resource manager should abort the tx when the TCP/IP connection drops, but some (db2?) don't. You need to keep the connection intact if you want to be sure it gets terminated cleanly, or rely on the crash recovery to tidy it up. Yes, Oracle is the same for local transactions. If you crash the connection it rolls back when auto-commit=false. If you explicitly close it without committing, it commits anyway - so much for auto-commit=false :-( So you have to do a rollback() before closing(), just to be sure. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167125#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...