Bugs item #590816, was opened at 2002-08-04 10:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=590816&group_id=22866
Category: JBossCX Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Larry Sanderson (lsanders) Assigned to: Nobody/Anonymous (nobody) Summary: XAProto Errors on closed XA Resources Initial Comment: Symptoms: An XA Resource (any - JDBC, JMS, etc..) is associated with a global transaction (tx1). That resource is closed, and put back in the free pool, but tx1 remains open. Another client, within another transaction (tx2) obtains the resource from the free pool. While the resource is associated with tx2, tx1 attempts to commit or roll-back. Result: XAException (errorCode=XAER_PROTO). Since most transactios are relatively short lived, and the pool is usually sufficiently large, it is rare for a connection to be used by a second client before the first transaction rolls-back or commits. Therefore this bug does not appear except under relatively heavy load. I have tracked the bug down to a change made 6 weeks ago on org.jboss.resource.connectionmanager.XATxConnection Manager. When an XAResource is is closed, it is first delisted with tha XA flag XAResource.TMSUSPEND. Because it is suspended subsequent commits and rollbacks are forced to first resume that transaction, then end it successfully (ie XAResource.start (TMRESUME); XAResource.end(TMSUCCESS)). (actually the JTA and XA/Open spec differ here: JTA requires both calls, but XA/Open only requires the second). But, if that resource has already been enlisted into another transaction then it is a protocol error (XAER_PROTO) to attempt to resume the old transaction. Prior to 6 weeks ago, XAConnections were delisted with the XA flag XAResource.TMSUCCESS. This allowed the resources to be committed and rolled back without first re-enlisting that resource, and avoiding these protocol errors. According to the cvs comments on XATxConnectionManager.java, this flag was switched to make SwiftMQ work correctly. I believe that this flag should be switched back to its original state - TMSUCCESS is the proper flag to use when a user requests to close a transaction. If this is not done, then at the least these connections should not be allowed back into the free pool until their corresponding transactions have been closed. -Larry ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=590816&group_id=22866 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
