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

[Mark Little (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBAS-4481?page=comments#action_12365221 ] 
            
Mark Little commented on JBAS-4481:
-----------------------------------

"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. "

You're allowed to pass Transaction via suspend and resume in JTA.

"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*? "

A thread can't just start a transaction and ignore it. Is this thread created by Seam, Hibernate or the application server. That would help to figure out where the code is doing that.

"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."

Thanks for the educational interlude!

"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?"

I already told you why we can't break the thread-to-transaction association in the case of timeout. JBossTM didn't do that, but did break it in a number of illegal places (like getStatus). We (whatever is creating the transaction to start with) should be cleaning up the association for sure. I'm unclear where that is at the moment and you're not giving me anything more to work on. Any chance you can send us your app so we can run it here and check? That may be the easiest way of tracking things down.


> Transaction timeouts leave garbage Status.ROLLEDBACK UserTransaction object bound to the thread
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-4481
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4481
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager
>    Affects Versions: JBossAS-4.2.0.GA
>            Reporter: Gavin King
>         Assigned To: Jonathan Halliday
>            Priority: Blocker
>             Fix For: JBossAS-4.2.1.CR1
>
>
> If a transaction timeout occurs, the UserTransaction object does not get cleaned up from the thread, even after the request ends and the thread returns to the pool. Future requests will not be able to begin() a transaction, since the STATUS_ROLLEDBACK UserTransaction throws this exception:
> Caused by: javax.transaction.NotSupportedException
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:79)
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.begin(BaseTransactionManagerDelegate.java:77)
> 	at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.begin(ServerVMClientUserTransaction.java:124)
> 	at org.jboss.seam.transaction.UTTransaction.begin(UTTransaction.java:29)
> This means that any transaction timeout that occurs will leave the application server in a permanently broken state and require a server restart. Hence 4.2.0.GA is currently unusable in production!
> This needs to be fixed in an immediate patch release.

-- 
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