PQ88648; 4.0.7: Transactional context not propagated correctly
 Downloadable files
 
Abstract
When a server calls a method that runs on a subordinate server and a setRollbackOnly call is made, this status change is not reflected back to the superior (originating) server.
 
Download Description
PQ88648 resolves the following problem:

ERROR DESCRIPTION:
This problem manifests when running in Dual Stack mode, meaning that each request from the client is executed in tandem on both servers. For simplicity, we will refer to the first stack as "old" (fall back version) and the other as "new" (new release) stack.

Sequence of events:

  1. Client(Swing) submitted request to "new" stack via RMI/IIOP.

  2. The New stack executes the requested method on Stateless Session Bean (SSB) with Supported TX attribute set.

  3. During execution of this method on "new" stack, it invokes another method with TX Required attribute set.

  4. The invoked method with TX Required attribute invokes SSB method on the second stack ("old" one) with Supported TX attribute set.

  5. The method on "old" stack with Supported TX attribute processes the request and invokes another method with Required TX attribute set.

  6. The invoked method with Required TX attribute that is running on "old" stack starts participating in Global transaction that has been initiated by "new" stack (at this point it runs DB2 SP request). During execution of this method, it failed because of some internal business logic. We detected it and explicitly set RollBack on the transactional context in that method on "old" stack.

  7. After transaction on "old" stack failed, we get back to "new" stack and check the status of the transaction via sessionContext.getRollbackOnly() call. For unknown reasons, it returns FALSE instead of TRUE. We also did not get any exception on that call, which would indicate that we are not in trans context, but the context has been explicitly set to true in the failed method on "old" stack. We even step in with debugger and double check the flags and flow.

  8. For unknown reasons, the transactional context was not propagated correctly to the new stack that starts and manages global transaction. It violates the transactional manager specification.


USERS AFFECTED:
All WebSphere Application Server users of distributed transactions.

PROBLEM CONCLUSION:
The transaction service will be changed so that when a transaction is marked for rollbackOnly in a subordinate server, the superior server will be informed. This will allow applications running in the superior server to detect this status change. To become effective, this fix must be applied to all servers involved in the transaction, and every server must be defined to use interop mode, by specifying the following JVM settings:

com.ibm.ejs.jts.jts.ControlSet.nativeOnly=false
com.ibm.ejs.jts.jts.ControlSet.interoperabilityOnly=true

PQ88653 must also be applied to all servers involved in the transaction.

RECOMMENDATION:
When a server calls a method that runs on a subordinate server and a setRollbackOnly call is made, this status change is not reflected back to the superior (originating) server. Applications in the superior node cannot determine if the transaction has been marked for rollback, if the status change was made in a subordinate server. However, the transaction does rollback properly.
 
Prerequisites
NONE
 
 
Installation instructions
Please review the readme.txt for detailed installation instructions.
 
URL LANGUAGE SIZE(Bytes)
Readme US English 2959
 
Download package
What is DD?
DOWNLOAD RELEASE DATE LANGUAGE SIZE(Bytes) Download Options
PQ88648_Fix 7/15/2004 US English 1115357 FTP DD
 
Technical support
1-800-IBM-SERV (U.S. Only)
 
Problems (APARs) fixed
PQ88648
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Java Transaction Service (JTS)
Operating system(s): HP-UX
Software version: 4.0.7
Software edition:
Reference #: 4007483
IBM Group: Software Group
Modified date: Aug 31, 2005