[
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