PK87857: ALLOW ROOT CAUSE OF TRANSACTIONROLLBACKEXCEPTION TO BE RETURNED TO AN EJB CLIENT.

Fixes are available

APAR status

Closed as program error.

Error description

When using JTA Synchronization, an exception is caused in the
"beforeCompletion" callback.  This exception is caught and
handled by the Enterprise JavaBeans (EJB) Container.  The EJB
Container rolls back the transaction and returns a
TransactionRollbackException to the client without any
root cause.  The lack of a root cause leaves the client not
knowing what actions to take or what caused the transaction to
be rolled back.

Local fix

Problem summary

****************************************************************
* USERS AFFECTED:  All users of IBM WebSphere Application      *
*                  Server V6.0.2, V6.1.0, V6.1.0 Feature Pack  *
*                  for Enterprise JavaBeans 3.0, and V7.0.0.   *
****************************************************************
* PROBLEM DESCRIPTION: Nested exceptions are not returned to   *
*                      a client when a transaction is rolled   *
*                      back.                                   *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
The existing APAR PK06177 describes conditions under which
nested exceptions may be lost (not nested) when a transaction
is rolled back.  This APAR is a continuation of APAR PK06177
in that this APAR will include more scenarios that were not
included in PK06177.  When the code is enabled (as will be
described below), this APAR will allow for the following
scenarios:
1) In looking at the javax.transaction.TransactionManager
interface, it can be seen that that the 'commit' method can
throw a number of methods.  When the EJB Container is managing
the transaction and calls the 'commit' method, if one of the
transactions defined on the method is thrown, the EJB
Container will catch it and discard it, and will return a
TransactionRolledbackException to a 'remote' caller or a
TransactionRolledbackLocalException to a 'local' caller.  As
such, the user will not see the root cause of the transaction
rollback.  However, the EJB Container should not discard this
method in cases where it can be returned to the client.  In
the 'local' case, the TransactionRolledbackLocalException
should contain the root cause, and this APAR, when enabled,
will allow the root cause of the roll back to be included
(nested).  In the 'remote' case, the APAR PK06177 describes
when the nested exception can be returned to the client, and
this APAR will allow an exception from the 'commit' method be
returned to the caller as described in APAR PK06177.
2) As descibed in #1, the 'commit' method on the
javax.transaction.TransactionManager interface may throw a
number of exceptions, two of which are Heuristic Exceptions.
Without this APAR enabled, if one of the Heuristic Exceptions
are caused, the EJB Container will return to the client either
a 'TransactionRolledbackLocalException' when a 'local' EJB
method is called or a 'TransactionRolledbackException' when a
'remote' EJB method is called.  In so doing, the exception can
be a bit misleading in that a Heuristic Exception indicates
that a heuristic descistion was made to rollback a
transaction.  That is, in the case of a
HeuristicMixedException, some resource may have been rolled
back, and other may not.  As such, the user should be aware of
the heuristic desiction by receiving the Heuristic Exception
as the root cause.
3) APAR PK06177 described that a RemoteException can be
returned to the caller only when the bean method which started
the transaction is the one to cause the transaction to
rollback.  The 'Exception Handling' chapter of the EJB
Specification mandates that a TransactionRolledbackException
must be thrown when a bean method runs in the context of the
caller's transaction.  However, in so doing, the root cause
exception causing the rollback will be lost.  This may not be
a desirable result.  With this APAR, the user has the option
to relax this requirement.  That is, to allow a
RemoteExcpetion to be returned from a remote EJB method even
if that method is running in the context of the caller's
transaction.  As an example, consider that EJB 1, method m1,
begins a Tx and calls EJB 2, method m2, where m2 causes an
unhandled exception.  In this case, the spec mandates that m1
would receive a TransactionRolledbackException.  This APAR
offers an option, when enabled, to allow a RemoteException to
be returned instead which will include any nested
exception(s).  The user must understand that this is a
violation of the EJB Specification and to use at their own
risk. For example, an application that depends on this
behavior being enabled may not be portable. Also, an
application that performs specific processing for a
TransactionRolledbackException may not behave as expected when
this behavior is enabled, since the application will see
a RemoteException instead.

Problem conclusion

With this fix, code will be added to support the scenarios
described above when the code is enabled.  The code is enabled
by a system property, and the scenarios above are enabeld when
the system property is set to a specific integer.  The system
property is named
"com.ibm.websphere.ejbcontainer.includeRootExceptionOnRollback".
The property can take the values 'true', 'false', or an
integer.  The integer values are defined to the following
options:

0 - Disables this property, same as setting 'false' (default).

1 - Enables APAR PK06177, same as setting 'true'.

2 - Enables the new code and scenarios of this APAR, that is,
includes more scenarios in which a RemoteException is
returned on a rollback (i.e. scenario #1 described above).
This value will also have the effect of allowing Heuristic
Exceptions to be returned rather than a
TransactionRolledbackLocalException (for a local client)
or TransactionRolledbackLocalException (for a remote
client), i.e. scenario #2 described above.  This value
also includes the same code/function enabled via value 1.

4 - Allows a RemoteException to be returned to the transaction
beginner even when a down stream EJB method causes the
transaction to be rolledback (i.e scenario #3 descibed
above).  This is an EJB Specification violation, that is,
the 'Exception Handling' chapter of the EJB Spec
states that when a method executes in the context of the
caller's transaction, and that method throws an
unhandled exception, the container must throw a
TransactionRolledbackException.  This value does nothing on
its own, that is, it must be applied with value 1 and/or
2 to be useful.

To enabled a combination of these options, one must sum the
integer for the options of interest.  For example, to enable
option 1 and 4 (1+4=5), one would set the property as follows:
'includeRootExceptionOnRollback=5'

As another example, to enable all options (2+4=6, or 1+2+4=7,
but recall that value 2 includes 1), one would set the
property as follows:
'includeRootExceptionOnRollback=6'

To set this property and one of its values, perform the
following steps:
1. Open the administrative console.
2. Select Servers.
3. Select Application Servers.
4. Select the server you want to configure.
5. In the Server Infrastructure area, select Java and
Process Management.
6. In the Server Infrastructure area, select Process
Definition.
7. In the Additional Properties area, select Java Virtual
Machine.
8. In the Additional Properties area, select Custom Properties.
9. Select the New box.
10. In the Name entry field, type
com.ibm.websphere.ejbcontainer.includeRootExceptionOnRollback
11. In the Value entry field, type one of the values of
interested which are described above.
12. Select OK.


The fix for this APAR is currently targeted for
inclusion in Service Levels (Fix Packs) 6.0.2.39, 6.1.0.29,
Enterprise JavaBeans 3.0 Feature Pack Fix Pack 29
(6.1.0.29), and 7.0.0.9 of WebSphere Application Server
versions 6.0.2, 6.1.0, and 7.0.0.

Please refer to the recommended updates page for delivery
information:
http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980

Temporary fix

Comments

APAR Information

APAR number
PK87857
Reported component name
WEBSPHERE APP S
Reported component ID
5724J0800
Reported release
61A
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2009-06-03
Closed date
2009-07-31
Last modified date
2015-10-15

APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:

Fix information

Fixed component name
WEBSPHERE APP S
Fixed component ID
5724J0800

Applicable component levels

R60A PSY
UP
R60H PSY
UP
R60I PSY
UP
R60P PSY
UP
R60S PSY
UP
R60W PSY
UP
R60Z PSY
UP
R61A PSY
UP
R61H PSY
UP
R61I PSY
UP
R61P PSY
UP
R61S PSY
UP
R61W PSY
UP
R61Z PSY
UP
R700 PSY
UP

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"6.1","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
29 December 2021

Tips

PK87857: ALLOW ROOT CAUSE OF TRANSACTIONROLLBACKEXCEPTION TO BE RETURNED TO AN EJB CLIENT.

Fixes are available

Subscribe

APAR status

Closed as program error.

Error description

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

APAR Information

APAR number

Reported component name

Reported component ID

Reported release

Status

PE

HIPER

Special Attention

Submitted date

Closed date

Last modified date

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Fix information

Fixed component name

Fixed component ID

Applicable component levels

R60A PSY

R60H PSY

R60I PSY

R60P PSY

R60S PSY

R60W PSY

R60Z PSY

R61A PSY

R61H PSY

R61I PSY

R61P PSY

R61S PSY

R61W PSY

R61Z PSY

R700 PSY

Document Information

Share your feedback

Need support?