Java 有没有办法释放饱和的连接池？

我正在glassfish服务器上使用OpenESB。 我们有一个与as400数据库一起工作的连接池

每隔几天我们就会出现以下错误： 分配连接时出错。原因：在用连接等于最大值- 池大小和过期的最大等待时间。无法分配更多连接

解除cp的最佳方法是重新启动服务器。 我们还成功地设置了另一个具有相同属性的cp

我的问题是: 有没有办法主动“告诉”cp释放其所有打开的连接

干杯，

---

Eran

执行此操作之前，请找出连接未正确释放的原因。听起来好像只有一个地方忘记了这一点（finally子句中是否有all close（））

我可以强烈推荐MichaelNygards“ReleaseIt！”，以获得让软件生产做好准备的技术

编辑#1：如果我正确理解您的描述，您的后端程序将进入QSYSOPR中的MSGW，这将导致挂起连接，直到给出响应为止，而在您的情况下，这几乎是不可能的。是否可以选择使用默认回复为“C”的配置文件，以允许故障作为异常传播给您

否则，您可以为连接或整个服务器设置24小时的超时时间？然后，至少这些连接最终会被关闭。这个解决方案虽然不能扩展，但是可以使开发更容易

---

请注意，也可以有一个单独的监视线程，定期查找MSGW，并在获取回拨堆栈进行事后分析后自动向他们发送答案。

如果您可以确定“正常”的上限连接使用时间（秒）您可以使用GlassFish的连接泄漏检测机制。在GF的管理控制台（我使用v2.1）中，转到Resources/JDBC/Connection Pools/[your cp]/Advanced，在“连接设置”下，将“泄漏回收”设置为true，并设置泄漏超时时间（以秒为单位）。

您在给Andersen的评论中提到，将抛出400条消息。您可以设置对这些消息的自动应答，以避免将异常消息保持打开状态。查看AS400上的WRKRPYLE（工作回复列表条目）命令，自动回复这些错误并避免挂起。

我遇到了这个问题，结果是事务管理。将@TransactionManagement（TransactionManagementType.BEAN）添加到类中解决了这个问题。就我而言，我不需要任何交易代码，但您的里程数可能会因您的要求而有所不同。

谢谢您的快速回复。我在每个相关的finally子句中都有close（）（很可能是这样的）问题是as400端可能抛出的异常，打开一个用户确认对话框。在未关闭之前，将不会释放连接。我想知道是否有一种方法不必永远等待as400上没有人真正监控的确认。我会尝试挖掘一点关于Michael Nygards“释放它”。如果连接在请求的中间，或者它必须是“空闲的”，那么这个工作会发生吗？因为这些发生在服务器的工作中（对于这个问题），这个选项可能是麻烦的。为该类型的一个作业设置它也会为相同类型的每个作业（即，与服务器的任何连接）设置它。可能有许多连接无法容忍默认回复。小心地执行。