PQ60431: AFTER PQ53415, EXCEPTION PROCESSING IN CONNECTION CREATION | |||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||
APAR status Closed as program error. Error description PQ52986 and PQ53415 added a fix for a problem where if the transaction timed out, the close that frees up the proxies associated for the connection would occur before the current work on the connection completed. In order to detect this problem, detection of work that was in progress when the transation timed out was added to preinvoke. A wait was added to the close processing so that the work could complete first and then notify the close to proceed. A notify was added to the postinvoke, so when the work completed the close would then occur. Unfortunately, this had an unforseen side effect for stale connection processing. . During a request to a database (this could be any request including getting a connection or excuting a statement), if an SQL exception occurs that is then translated to a stale connection, the processing on the connection will hang and the connection will no longer be usable or recoverable. This is because the destroy connection processing that occurs during the translation causes a close on the proxy which causes a wait to occur that will never be woken up because it is waiting for a postinvoke that can never occur because it comes after the translate processing. . This will be fixed by adding more logic to distinguish between the transaction time out and the destroy and not cause a wait in the destroy case.Local fix Problem summary **************************************************************** * USERS AFFECTED: WebSphere Application Server users of * * Connection Manager * **************************************************************** * PROBLEM DESCRIPTION: Connection hangs after receiving a * * StaleConnectionException * **************************************************************** * RECOMMENDATION: * **************************************************************** Possible hangs when processing StaleConnectionExceptions. Connections become unusable and do not recover.Problem conclusion During a request to a database (this could be any request including getting a connection or excuting a statement), if an SQL exception occurs that is then translated to a stale connection, the processing on the connection will hang and the connection will no longer be usable or recoverable. This is because the destroy connection processing that occurs during the translation causes a close on the proxy which causes a wait to occur that will never be woken up because it is waiting for a postinvoke that can never occur because it comes after the translate processing. . This has been fixed by adding more logic to distinguish between the transaction time out and the destroy and not cause a wait in the destroy case.Temporary fix Custromer has the E-Fix and it fixed the problem.Comments
APAR is sysrouted FROM one or more of the following: PQ55402 APAR is sysrouted TO one or more of the following: Modules/Macros
|
Document Information |
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ60431
IBM Group: Software Group
Modified date: Apr 23, 2002
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.