[jboss-jira] [JBoss JIRA] Commented: (JBAS-4481) Transaction timeouts leave garbage Status.ROLLEDBACK UserTransaction object bound to the thread

[ http://jira.jboss.com/jira/browse/JBAS-4481?page=comments#action_12365218 ] Gavin King commented on JBAS-4481: ---------------------------------- "In a multi-threaded environment where multiple threads may be running in the scope of the same transaction " In a Java EE environment, "multiple threads ... running in the scope of the same transaction" is a vanishingly rare case and one that I'm not even convinced is actually supported (there does not seem to be any standard way to pass a txn context between container threads, and you're not supposed to start your own threads). Perhaps I'm wrong on this, but that's what I've always understood. Regardless, it is clear that the association should be cleaned up before the thread is returned to the thread pool, . "What JBossTS does (and has always done) is roll back the transaction that has timed out and leave it associated with the various threads." Those threads are in a THREAD POOL, and are going to be re-used in future requests that have nothing to do with the original transaction. That is why the Java EE spec (read it) *requires* that you clean up any open transaction at the end of every request. The Java EE spec is smart enough to know that an application server can't assume that applications are "well-behaved", as defined by Mark Little this month (where the definition of "well-behaved" changes arbitrarily between minor releases of the application server in question). Application servers aren't supposed to fall over in a heap just because an application fails to clean up in an exceptional case in one thread. That's the whole point. Besides which, this is a strange definition of "well-behaved". How can it possibly make sense to require a call to rollback() or commit() on a transaction with the status ROLLEDBACK? The transaction is rolled back. Why should I need to roll it back *again*? Now, if it was ROLLBACK_ONLY, that's a different case, a well-behaved application should to something to it, but even in this case the Java EE spec requires that the association to the current (pooled) thread is destroyed before returning the thread to the pool. Actually I'm kinda confused how we even got to this status in the first place, the definition of Status.ROLLEDBACK states: "A transaction is associated with the target object and the outcome has been determined as rollback. It is likely that heuristics exist, otherwise the transaction would have been destroyed and NoTransaction returned." I don't see why there are heuristics in the case of a simple transaction timeout against a single resource? Is that normal? Why didn't we just go straight to NO_TRANSACTION? -- 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