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

Question

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

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

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

2. MDB解决方案是Java EE的首选异步解决方案，但这似乎相当重，但具有让app服务器处理管理MDB线程池的额外好处。 （目前在我的名单上排名第一）

3. ESB。 这甚至更重，并增加了更多的网络和处理时间。 但它允许您设置单个服务超时。 还有一个问题是，在大公司中实施它将需要永远，所以可能对我的时间框架不实用。

你们有更好的想法吗？

Answer 1

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

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

WorkManager和TimerManager API

Answer 2

我们使用MDB，其中队列持久存储在数据库中，如果系统出现故障，该数据库的好处是不会丢失消息。

您可能还希望在参与方之间建立异步合同。 我的意思是客户端会向您发送消息，而不是您进行大量重量级处理并返回响应，您只需发送确认响应，然后向其发送异步消息并获得完整结果。

您还应该建立一个协议，允许客户端在已建立的时间内未收到完整响应时重新发送消息。

Answer 3

您可以尝试使用Atomikos MessageDrivenContainers（消息驱动的POJO）的轻量级 MDB方法。 您的应用程序将更轻量级，更易于测试，并且可能更具可扩展性。

看到 http://www.atomikos.com/Publications/J2eeWithoutApplicationServer 。

HTH

家伙