PQ67535: STALECONNECTIONEXCEPTION IS THROWN WHEN THERE ARE STALE JDBC CONNECTIONS AND A CLIENT ATTEMPTS A JNDI LOOKUP. | |||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description This problems occurs when stale JDBC connections are in the WebSphere connection pool, and a client attempts a JNDI lookup. When the naming component gets a connection from the pool and attempts to get data from the WebSphere repository, a StaleConectionException is thrown. The naming component then wraps the StaleConnectionException in a new NamingException which it throws back to the client. Instead, the naming component should retry the JDBC operation before throwing a NamingException. Addnl keywords: ServiceUnavailableExceptionLocal fix Problem summary **************************************************************** * USERS AFFECTED: Users who use the WebSphere Applicaiton * * Server Advanced Edition, release 4.0.5 or * * any releases prior to 4.0.5. * * * **************************************************************** * PROBLEM DESCRIPTION: When the database server used for the * * admin repository is stopped and * * restared, name server operations * * against the database will initially * * fail, when in principle, the name * * server could retry the naming * * operation. This would avoid the * * need for naming clients to perform * * the retry. * **************************************************************** * RECOMMENDATION: * **************************************************************** When stale JDBC connections are in the WebSphere connection pool, the name server will receive a StaleConnectionException when it uses a stale connection to access the name space database. Since the connection pool is flushed of all stale connections when the StaleConnection exception is thrown, and since Naming operations are performed with a new transaction (so that a rolled back transaction does not create a problem), the naming operation can be retried (with a new transaction). Before this e-fix, the name server attempted no retries and instead, threw an exception. This exception will usually be externalized as a JNDI NamingException because naming clients are typcially JNDI clients.Problem conclusion Retry logic was added to the name server so that operation resulting in unexpected exceptions are retried. New properties were defined to control the number of retries (com.ibm.websphere.naming.db.retrycount, with a default of 2) and the delay between retries (com.ibm.websphere.naming.db.retrydelay with a default of 2000 milliseconds).Temporary fix A temporary fix on WAS 4.0.4 was sent over to the customer on 10/22. The initial feedback are positive and the customer is running more complicated test scenario now against the fix. Waiting for that result.Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
SRLS
|
Document Information |
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ67535
IBM Group: Software Group
Modified date: Sep 17, 2003
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.