如何处理陈旧的连接？ [英] How to handle stale connections?

问题描述

我们是一个J2EE应用程序，在最近搬到生产的Mainframe / DB2后端的Websphere 6.1上使用Struts-EJB-Hibernate。

当用户首次登录应用程序或某些时候间歇性地发生此异常时，我们正在收到陈旧的连接异常。

在第二次尝试用户能够登录到应用程序。我得到的确切的错误消息是

  empcom.ibm.websphere.ce.cm.StaleConnectionException：
执行失败由于分配协议错误导致对话的释放。 
由于在目标系统上检测到永久性错误状况，所请求的命令无法完成。 
 DB2ConnectionCorrelator：AC100B80.A260.090107181206 
  

启用 PRETEST 选项在网站设置，并给出间隔为60秒，但仍然我得到这个问题..

分享您的意见，并帮助我

如果您需要，我可以给你更多的细节。

提前感谢

解决方案

我们在我们的一个生产系统的早上首次登录时遇到了同样的问题。
解决方案是将连接池的最小大小设置为零。

将最小大小设置为大于零的值（例如，一个），定时当连接被检测为无效时，它们将从池中删除，但是其中一些（在上面的示例中，最后一个示例中）保留在池中（如果最小大小为1，则一个连接停留在池中，即使它不是一个有效的连接）。

下次应用程序请求连接时，提供无效的连接，导致异常。

将最小大小设置为零，所有非有效连接都将从池中删除，因此无法连接到应用程序提供的连接尚未生效（因为如果有效，它将保持在池中，如果没有，则从池中删除）。

使用预测试可能是一个有效的替代方案，但会花费额外的努力，因为每次该连接正在提供给应用程序，已经过测试。

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

解决方案

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.

这篇关于如何处理陈旧的连接？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！