3

我需要启动一个长时间运行的批处理类型的工作，而长期以来我们谈论的工作可能需要几个小时。具有运行此长时间运行作业的逻辑的 ejb 将与 NoSQL 存储通信并加载数据等。

因此，我正在使用 JMS MDB 异步执行此操作。但是，由于每个作业可能需要一个小时或更长时间（假设最多 4 小时），我不希望 MDB 中的 onMessage() 方法等待这么长时间。因此，我正在考虑在 onMessage() MDB 方法中触发异步 ejb，以便在调用批处理 ejb 运行程序后立即将 MDB 返回到池中。

将异步 ejb 方法调用与 MDB 结合起来有意义吗？大多数示例建议使用 1 或其他来实现相同的目标。

如果要从 MDB 调用的 ejb 不是异步的，则 MDB 可能会等待很长时间。

请指教。

4

3 回答 3

3

我会简化一些事情：使用@Schedule 调用@Asynchronous 并忘记JMS。少一件可能出错的事情。

虽然还没有准备好迎接黄金时间，但 JSR 352：批处理应用程序看起来非常适合这类东西。

https://blogs.oracle.com/arungupta/entry/batch_applications_in_java_ee

于 2013-02-18T14:52:07.387 回答
1

我认为皮特回答了大部分问题。如果你只使用 mdb 来获得异步行为，你可以尽快触发 @Asynchronous 。

但是，如果您对 JMS 实现可能在可靠性、持久队列、缓慢的消费者策略、作业优先级等方面提供的任何其他功能感兴趣，您应该坚持使用 mdb:s

在 ejb 3.1 中引入 @Asynchronous 的原因之一是在不需要其他 JMS/MDB 特性时提供一种更轻量级的异步处理方式。

于 2013-02-01T14:53:05.467 回答
1

我想这是一个品味问题。

如果您有来自 JMS 池的线程运行您的作业，或者您有一个异步 ejb 执行此操作，则最终结果将是相同的 - 某个线程将被某个池阻塞。

从 MDB 生成异步 bean 并没有错，因为您可能希望由消息传递接口触发作业，但您可能不想阻塞线程池。此外，考虑到事务通常在一小时之前默认超时，因此如果您出于某种原因执行 MDB 事务，您可能需要考虑在 onMessage 中触发该异步 ejb。

于 2013-02-01T14:17:33.003 回答