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:
Client(Swing) submitted request to "new" stack via RMI/IIOP.
The New stack executes the requested method on Stateless Session Bean
(SSB) with Supported TX attribute set.
During execution of this method on "new" stack, it invokes another
method with TX Required attribute set.
The invoked method with TX Required attribute invokes SSB method on
the second stack ("old" one) with Supported TX attribute set.
The method on "old" stack with Supported TX attribute processes the
request and invokes another method with Required TX attribute set.
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.
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.
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:
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.