PQ88648: TRANSACTIONAL CONTEXT IS NOT PROPAGATED CORRECTLY TO THE EJB ON DIFFERENT SERVER WHICH STARTS AND MANAGES THE TRANSACTION

 Fixes are available

PQ88648; 4.0.7: Transactional context not propagated correctly
5.0.2.12: WebSphere Application Server 5.0.2 Cumulative Fix 12
5.0.2.13: WebSphere Application Server 5.0.2 Cumulative Fix 13
5.0.2.14: WebSphere Application Server 5.0.2 Cumulative Fix 14 for AIX
5.0.2.14: WebSphere Application Server 5.0.2 Cumulative Fix 14 for Solaris
5.0.2.14: WebSphere Application Server 5.0.2 Cumulative Fix 14 for HP-UX
5.0.2.14: WebSphere Application Server 5.0.2 Cumulative Fix 14 for Windows
5.0.2.14: WebSphere Application Server 5.0.2 Cumulative Fix 14 for Linux
5.0.2.15: WebSphere Application Server 5.0.2 Cumulative Fix 15 for Windows
5.0.2.15: WebSphere Application Server 5.0.2 Cumulative Fix 15 for Solaris
5.0.2.15: WebSphere Application Server 5.0.2 Cumulative Fix 15 for AIX
5.0.2.15: WebSphere Application Server 5.0.2 Cumulative Fix 15 for Linux
5.0.2.15: WebSphere Application Server 5.0.2 Cumulative Fix 15 for HP-UX
5.1.1.9: WebSphere Application Server V5.1.1 Cumulative Fix 9 for HP-UX
5.1.1.9: WebSphere Application Server V5.1.1 Cumulative Fix 9 for AIX
5.1.1.9: WebSphere Application Server V5.1.1 Cumulative Fix 9 for Solaris
5.1.1.9: WebSphere Application Server V5.1.1 Cumulative Fix 9 for Windows
5.1.1.9: WebSphere Application Server V5.1.1 Cumulative Fix 9 for Linux
5.0.2.16: WebSphere Application Server 5.0.2 Cumulative Fix 16 for AIX
5.0.2.16: WebSphere Application Server 5.0.2 Cumulative Fix 16 for HP-UX
5.0.2.16: WebSphere Application Server 5.0.2 Cumulative Fix 16 for Linux
5.0.2.16: WebSphere Application Server 5.0.2 Cumulative Fix 16 for Windows
5.0.2.16: WebSphere Application Server 5.0.2 Cumulative Fix 16 for Solaris
5.0.2.8: WebSphere Application Server V5.0.2 Cumulative Fix 8
5.1.1.10: WebSphere Application Server V5.1.1 Cumulative Fix 10 for HP-UX
5.1.1.10: WebSphere Application Server V5.1.1 Cumulative Fix 10 for AIX
5.1.1.10: WebSphere Application Server V5.1.1 Cumulative Fix 10 for Solaris
5.1.1.10: WebSphere Application Server V5.1.1 Cumulative Fix 10 for Windows
5.1.1.10: WebSphere Application Server V5.1.1 Cumulative Fix 10 for Linux
5.0.2.17: WebSphere Application Server 5.0.2 Cumulative Fix 17 for Windows
5.0.2.17: WebSphere Application Server 5.0.2 Cumulative Fix 17 for Solaris
5.0.2.17: WebSphere Application Server 5.0.2 Cumulative Fix 17 for HP-UX
5.0.2.17: WebSphere Application Server 5.0.2 Cumulative Fix 17 for Linux
5.0.2.17: WebSphere Application Server 5.0.2 Cumulative Fix 17 for AIX



APAR status
Closed as program error.

Error description
We are running in Dual Stack mode. It means each request from
Client should be executed in tandem on both servers.
For simplicity lets call one stack "old" (fall back version) and
another "new" (new release) stack.
.
Here is the 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 process
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 start 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 to us reason
it returns FALSE instead of TRUE. Plus we 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 reason the transactional context was not
propagated correctly to the new stack that start and managed
global transaction. It violates the transactional manager spec.
Local fix Problem summary
****************************************************************
* USERS AFFECTED: All WebSphere Application Server users of    *
*                 distributed transactions.                    *
****************************************************************
* PROBLEM DESCRIPTION: setRollbackOnly status is not reflected *
*                      back to superior server.                *
****************************************************************
* 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. The transaction
does rollback correctly though.
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, please note the following:
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
In addition, the fix for 
PQ88653 must be applied to all
servers involved in the transaction.
Temporary fix
Jar files were sent for testing on Mon 17 may 2004.
Comments
APAR information
APAR number PQ88648
Reported component name WEBPSHERE AE HP
Reported component ID 5630A2203
Reported release 400
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Submitted date 2004-05-10
Closed date 2004-07-15
Last modified date 2004-07-15

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:
PQ89426 PQ89427

Modules/Macros
COORD CRNTSET CURRENT UOWCOORD UOWCURR USRTRAN

SRLS

Fix information

Applicable component levels
R400 PSY    UP


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ88648
IBM Group: Software Group
Modified date: Jul 15, 2004