APAR status |
Closed as program error.
| Error descriptionPQ52986 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 fixProblem 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 information | APAR number | PQ55402 | Reported component name | WAS ADVANCED AI | Reported component ID | 5648C8400 | Reported release | 350 | Status | CLOSED PER | PE | NoPE | HIPER | NoHIPER | Submitted date | 2001-12-03 | Closed date | 2002-04-23 | Last modified date | 2002-04-23 |
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:APAR is sysrouted FROM one or more of the following:
PQ60431
Modules/Macros APAR is sysrouted TO one or more of the following:PQ60431Modules/Macros
|
Fix information |
Fixed component name | WAS ADVANCED AI | Fixed component ID | 5648C8400 |
Applicable component levels | R350 PSY | UP |
|