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

Question

我在职业生涯中遇到过几次的问题是在分层服务架构中，如果单个下游系统进入所有线程都被死锁或某种形式消耗的状态，则它可能会导致整个客户端应用程序崩溃该系统中的无限循环错误。在这些情况下，Java EE 服务器上的服务器套接字仍在接受和排队来自客户端应用程序的请求。这会导致客户端应用程序耗尽所有等待来自正确建立的套接字连接的响应的线程。然后所有用户都被锁定在系统之外，因为他们的请求也在排队。

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

1. 下游请求的独立线程池。这成为一个问题，因为您在系统中混合了空闲线程的数量，创建了许多需要有足够线程以确保完整吞吐量的小池。生成线程意味着您需要自己处理事务和安全上下文。不是真正受支持的 Java EE 解决方案。

2. MDB 解决方案，Java EE 的首选异步解决方案，然而这看起来相当重量级，但具有让应用服务器处理 MDB 线程池管理的额外好处。 (目前在我的名单上排名第一)

3. ESB。这甚至更重，并增加了更多的网络和处理时间。但它允许您设置单独的服务超时。还有一个问题是，在大公司中实现需要很长时间，所以在我的时间范围内可能不切实际。

你们有什么更好的想法吗？

Answer 1

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

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

WorkManager and TimerManager API