PK07143: WHEN AN EJB ON A SERVER CALLS ANOTHER EJB ON ANOTHER SERVER, IF CLIENT INACTIVITY TIMEOUT IS MET THE FIRST SERVER CAN'T TELL

 Fixes are available

5.1.1.8: WebSphere Application Server 5.1.1 Cumulative Fix 8 for AIX
5.1.1.8: WebSphere Application Server 5.1.1 Cumulative Fix 8 for Windows
5.1.1.8: WebSphere Application Server 5.1.1 Cumulative Fix 8 for HP-UX
5.1.1.8: WebSphere Application Server 5.1.1 Cumulative Fix 8 for Solaris
5.1.1.6: WebSphere Application Server Version 5.1.1 Cumulative Fix 6
5.1.1.7: WebSphere Application Server Version 5.1.1 Cumulative Fix 7
5.1.1.8: WebSphere Application Server 5.1.1 Cumulative Fix 8 for Linux



APAR status
Closed as program error.

Error description
Given the following topology:

   Server 1             Server 2
    EJB 1                EJB 2

If EJB 1 makes a call to EJB 2, and EJB 2 returns correctly, but
the transaction on EJB 1 lasts long enough to cause a client
inactivity timeout on Server 2, Server 1 will not know until its
transaction is finished running.  If the transaction lasts a
long time, the EJB on Server 1 could potentially run for 30
minutes or more and not realize it will have to perform a
rollback, because of the client inactivity timeout.

The operation is working as designed, but Server 1 should have
some way of knowing that it will have to perform a rollback
before it spends 30 minutes doing work that will just get rolled
back anyway.  Currently it cannot know.
Local fix
There are two options:

1.  Set the client inactivity timeout to a value long enough to
avoid causing the rollback in the first place.

2.  Use an intermediary EJB on Server 1 that uses
TX_REQUIRES_NEW or TX_NOT_SUPPORTED before it then forwards the
request to Server 2.  In this way, the transaction on Server 1
will be suspended before the client call to Server 2.  When the
transaction on Server 1 resumes, it will not care about keeping
Server 2 in the loop and the timeout won't occur because Server
2 was never made a part of Server 1's transaction.
Problem summary
****************************************************************
* USERS AFFECTED: All WebSphere Application Server users.      *
****************************************************************
* PROBLEM DESCRIPTION: When an EJB on a server callls another  *
*                      EJB on another server, when client      *
*                      inactivity timeout occurs the first     *
*                      server can't detect the timeout.        *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
If EJB 1 makes a call to EJB 2, and EJB 2 returns correctly,
but the transaction on EJB 1 lasts long enough to cause a
client inactivity timeout on Server 2, Server 1 will not know
until its transaction is finished running.  If the transaction
lasts a long time, the EJB on Server 1 could potentially run
for 30 minutes or more and not realize it will have to perform
a rollback, because of the client inactivity timeout.

The client inactivity timeoutfunction is working correctly,
but Server 1 should have some way of knowing that it will have
to perform a rollback before it spends 30 minutes doing work
that will just get rolled back anyway.  Currently it cannot
know.
The problem is caused because server 2, in the above scenario,
does not inform server 1 that the transaction is about to be
rolled back.
Problem conclusion
Class TransactionImpl will be changed so that when the client
inactivity timeout occurs, a setRollbackOnly will be sent to
the originating server so that EJB 1 can determine its
current transactional state.
The fix for this APAR is currently targeted for inclusion in
fixpack 5.1.1.6. 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 PK07143
Reported component name WAS BASE 5.0
Reported component ID 5630A3600
Reported release 10W
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Special Attention NoSpecatt
Submitted date 2005-06-10
Closed date 2005-07-11
Last modified date 2005-11-10

APAR is sysrouted FROM one or more of the following:

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

Modules/Macros
TRANIMPL          

Publications Referenced

Fix information
Fixed component name WAS BASE 5.0
Fixed component ID 5630A3600

Applicable component levels
R003 PSN    UP
R00A PSN    UP
R00H PSN    UP
R00I PSN    UP
R00P PSN    UP
R00S PSN    UP
R00W PSN    UP
R103 PSY    UP
R10A PSY    UP
R10H PSY    UP
R10I PSY    UP
R10P PSY    UP
R10S PSY    UP
R10W PSY    UP


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > General
Operating system(s):
Software version: 10W
Software edition:
Reference #: PK07143
IBM Group: Software Group
Modified date: Nov 10, 2005