Hi, I'm looking for guidance on how we are supposed to be handling this case, because the behavior we are seeing is not what we want. Components in use: Jboss 4.2.2-GA, Windows Server 2003 , Jboss-Messaging 1.4.2. Here is the issue: We have a stateless session bean that is marked as using container managed transactions. We're have the default transaction timeout set as specified in jboss-service.xml of 180 seconds. When one of our EJB methods is entered (marked as 'required' for the transaction), we get a JDBC connection from the data-source that we have created via a *-ds.xml file in the jboss deploy directory. When we get the connection, the auto-commit flag is set to false, which is expected. We then run a bunch of sql commands (inserts, updates). Let's say the transaction timeout hits for some reason like the queries we're running are taking too long. When the timeout occurs I see the following entries in our log4j log: 2009-04-17 17:32:30,075 [ Thread-3] WARN com.arjuna.ats.arjuna.logging.arjLoggerI18N : [com.arjuna.ats.arjuna.coordinator.BasicAction_58] - Abort of action id -53ef9ed4:e28:49e91dfb:1de invoked while multiple threads active within it. 2009-04-17 17:32:30,075 [ Thread-3] WARN com.arjuna.ats.arjuna.logging.arjLoggerI18N : [com.arjuna.ats.arjuna.coordinator.CheckedAction_2] - CheckedAction::check - atomic action -53ef9ed4:e28:49e91dfb:1de aborting with 1 threads active! At that exact time when the transaction times out, the container is rolling back the transaction, and that's fine. The problem here is that our thread keeps running, AND the connection's auto-commit flag got set back to true. The end result is that any inserts/updates we did after the timeout, get committed immediately leaving the database in a bogus state. So here are my questions: 1) Is this expected behavior to have the rollback occurring in parallel to the ejb thread continuing to run? 2) Why is the auto-commit getting set to true when the timeout occurs? 3) Shouldn't the rollback occur synchronously after our EJB method returns into the jboss ejb stub code? 4) What is the correct way we're supposed to be handling the transaction timeout so the database doesn't wind up hosed? We see this exact same behavior with jboss and mysql, and jboss and sql server. 5) The old jboss transaction manager configuration used to allow you to interrupt the thread, instead of continuing to let it run. I understand this feature has been removed for legitimate reasons as explained by this thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=125962 . This would have been our preferred approach to fix this problem if it were still supported. Thanks for the help, Joe View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227656#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...