How to handle stale connections?

Question

Hi Friends,

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..

thanks in advance

Answer 1

connection time out-180 minimum connections-1 maxmum connections-10 reap time -180 unused time out -1800 aged time out - 0 purge policy- entrie pool

We can not handle to stale exception in our code since we using hibernate where hibernate cgf and webshere setting will open/deal connections and other stuffs with DB

can you please suggess how to avoid this issue?

Answer 2

When i was surfing about the prestest connection option i found this one

http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg1PK66322

this link tells that pretest should not be used with purge policy is entire pool is it true? but the webshere documentation says entire pool purge policy is good to avoid stale data in connection pool

i am confused :(

Answer 3

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

Answer 4

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.