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 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() 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=swg27004980Temporary fix Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: PK15024 Modules/Macros
Publications Referenced
|
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
(C) Copyright IBM Corporation 2000, 2008. All Rights Reserved.