Java的长事务时间解决方案？

Question

我在职业生涯中遇到的一个问题是，在一个分层的服务体系结构中，如果整个客户端应用程序陷入死锁或系统中某种无限循环错误的状态，那么一个下游系统就会导致整个客户端应用程序崩溃。在这种情况下，Java服务器上的服务器套接字仍在接受来自客户端应用程序的请求并将其排队。这会导致客户端应用程序耗尽所有等待正确建立的套接字连接响应的线程。然后所有用户都被锁在系统之外，因为他们的请求也在排队。

我想出了一些解决方案，但我想知道社区是否有更好的解决方案。

1. 用于下游请求的隔离线程池。这成为一个问题，因为您在系统中复合了空闲线程的数量，创建了许多需要有足够线程以确保完全吞吐量的小型池。生成线程意味着您需要自己处理事务和安全上下文。实际上不是一个受支持的Java解决方案。
2. MDB解决方案是Java的首选异步解决方案，但这似乎相当重，但它的另一个好处是让应用服务器处理MDB线程池的管理。(目前是我名单上的第一位)
3. ESB.这是更沉重的重量和增加更多的网络和处理时间。但它允许您设置单独的服务超时。还有一个问题，那就是在一家大公司里要花很长时间才能实现，所以对我的时间范围来说可能不太实际。

你们有什么更好的主意吗？

Answer 1

您是正确的，因为MDB案例是正常的解决方案，它通常也支持超时，这将有助于防止挂起的请求。尽管如此，它可能并不能真正解决问题，但只需将备份转移到JMS队列，而不会将响应发送回客户端。当然，如果几个服务中只有一个导致了这个问题，那么其他服务现在仍然可以访问。

您的建议(1)也可以通过commonj WorkManager在WorkManager或Weblogic上完成。它将允许您在这些环境中创建托管线程，并且非常轻量级。

WorkManager和TimerManager API

Answer 2

我们使用MDB，其中队列被持久化在数据库中，这样做的好处是，如果系统崩溃，消息不会丢失。

您还可能希望在参与方之间建立异步合同。我的意思是，客户端将向您发送一条消息，而不是您执行大量繁重的处理和返回响应，您只需发送一个确认响应，然后将一个异步消息发送给他们，得到完整的结果。

您还应该建立一个协议，如果客户端在规定的时间内没有收到完整的响应，就可以重新发送消息。

Answer 3

您可以使用Atomikos MessageDrivenContainers (消息驱动的POJO)尝试一种轻量级的MDB方法。您的应用程序将是更轻，更好的测试，并可能更可伸缩。

见http://www.atomikos.com/Publications/J2eeWithoutApplicationServer。

HTH

盖伊