How to handle stale connections?

问题:

Ours is a J2EE app, using Struts-EJB-Hibernate on Websphere 6.1 over Mainframe/DB2 backend, that was recently moved to production.

We are getting stale connection exception when the user login to the application first time or some times this exception occurs intermittently.

on the second try the user able to log in to the application. The exact error message i am getting is

empcom.ibm.websphere.ce.cm.StaleConnectionException: 
Execution failed due to a distribution protocol error that caused deallocation of the conversation.  
The command requested could not be completed because of a permanent error condition detected at the target system.  
DB2ConnectionCorrelator: AC100B80.A260.090107181206

I enabled PRETEST option in webshere settings and gave the interval as 60 sec, but still i am getting this issue..

kindly share your views and help me

i can give you more details if you need.

回答1:

We had the same issue at first login in the morning on one of our production systems. Solution was to set the minimum size for the connection pool to zero.

With minimum size set to a value greater than zero (e.g., one), timed out connections are removed from the pool when they are detected as not valid, but some of them (in the example above, the last one) remains in the pool (if the minimum size is one, one connection stays in the pool, even if it is not yet a valid connection).

Next time an application request a connection, the not valid one is served, resulting in the exception.

Setting minimum size to zero, all non valid connections are removed from the pool, so there is no chance the connection served to the application is not yet valid (because, if it is valid, it stays in the pool, if it is not, is removed from the pool).

Using the pretest could be a valid alternative, but will take an extra effort, because every time the connection is being served to the application, is tested.

回答2:

i got the answer for this

using pretest old connection and new connection we can solve this issue.. the pretest query should be a basic query (select sysdate from ..)which runs anytime..

and time interval should be maximum hence the application server will not get overhead