java - EJB定时器性能

Question

我正在尝试决定是否在我的应用程序中使用 java-ee 计时器。我使用的服务器是Weblogic 10.3.2

需求是:从 EJB 调用异步 Web 服务一小时后，如果尚未调用异步回调方法，则需要执行某些操作。有关回调方法是否已被调用以及调用执行日期的信息存储在数据库中。

我看到的两种可能性是:

1. 使用批处理流程，每半小时查找所有超过一小时没有响应的调用，并执行所需的操作。
2. 在每次调用 ws 后创建一个一小时的计时器，并在 @Timeout 方法中检查是否有答案，如果没有，则执行所需的操作。

从纯粹的编程角度来看，第二个看起来更简单、更干净，但我担心如果假设在某一时刻创建了 100.000 个计时器，可能会出现性能问题。

有什么想法吗？

Answer 1

拥有更专业的流程会更好。真正的问题是10万的问题。这取决于您的行动需要多长时间。

因为很容易看出，EJB 计时器每秒都会启动 30 个线程来处理所有当前待处理的作业，因为这就是它的工作原理。

此外，计时器是持久的，因此您的 EJB 管理的计时器表将每秒保存和删除 30 行(总共 60 行)，假设每小时有 100K 事务。

因此，大量工作发生得非常快。我可以很容易地看到系统只是“落后”并且永远无法 catch 。

专用进程的重量会轻得多，也许可以对操作调用进行批处理(每个线程调用 5 个操作，而不是每个线程调用一个操作)等。如果您不必保留计时器事件，那就太好了，但是就是这样。为了安全起见，您几乎可以轻松地将计时器事件附加到文件中，并将它们保存在内存中。系统重新启动时，您可以重新加载该文件，然后滚动该文件(每小时创建一个新文件，在全部使用完后删除旧文件等)。这将节省大量数据库流量，但您可能会失去数据库的事务性质。

无论如何，我认为您不想为此使用 EJB 计时器，我认为它并不是真正为这种流量而设计的。但你总是可以测试一下看看。确保测试重新启动容器，看看它在表中处理 100K 待处理计时器作业时效果如何。