JBoss EJB2 计时器服务 - 多个服务器，单个计时器表？
我在任何地方的 JBoss 文档中都找不到这个，所以我在这里询问。
多个非集群 JBoss 实例是否可以访问并共享同一个 TIMERS 表（由 EJB2 Timers Service 使用）而不互相干扰，或者每个实例都需要自己的表吗？
对于集群来说，集群中的所有节点都必须能够访问 TIMERS 表吗？还是它们直接通过网络共享信息？
预先感谢您的一些澄清！
富有的
I can't find this in the JBoss documentation anywhere, so am asking here.
Can multiple, non-clustered JBoss instances access and share the same TIMERS table (as used by EJB2 Timers Service) without upsetting each other, or does each one need its own table?
In the case of a cluster, is it essential that the nodes in the cluster all have access to the TIMERS table, or do they share information directly over the network?
Thanks in advance for some clarification!
Rich
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是一个老问题，但也许对某人来说仍然有用，所以我会尝试回答它。
假设同一个 Timers 表可以在不在集群中执行的不同服务器之间共享（事实上我认为这是可能的），则会出现与 TimerService 实现相关的几个问题，例如：假设每个服务器都部署了相同的 Timers，每个计时器的实例将与该表上的不同记录相关联吗？如果是这样，当定时器到期时，业务逻辑将被执行多次。如果部署过程只为每个计时器生成一条记录，那么当不同的 TimerService 尝试同时访问/修改相同的信息时，TimerService 是否正确执行？
另一方面，如果这个想法背后的动机是实现某种容错，那么仍然存在所有服务器必须部署相同的 Timer 的问题，否则 TimerService 可以尝试执行未部署在服务器中的 Timer服务器。
提供高可用性的解决方案已经实现，称为 HATimerService。
集群中只有一张Table，但不同的是，每次都存在唯一一个活跃的TimerService，当执行TimerService的节点出现故障时，另一个节点成为Master，因此节点之间不存在定时器信息交换。信息可在数据库中找到
This is an old question but maybe it could still be useful for someone, so I will try to answer it.
Assuming that the same Timers table could be shared among different servers that doesn't execute in a cluster (in fact I think this is possible) several issues related to TimerService implementation will appear, e.g.: supposing that each server has deployed the same Timers, will be each Timer's instance associated with different records on this table?. If so, the business logic will be executed more than once when the Timers expire. In case that the deploy process only generates a record per Timer, does the TimerService execute properly when different TimerServices try to access/modify the same information concurrently?
On the other hand, if the motivation behind this idea is to achieve some kind of fault tolerance, still exists the problem that all your servers must have deployed the same Timers, otherwise a TimerService can try to execute a Timer that is not deployed in the server.
The solution for to offer High Availability is already implemented and is called HATimerService.
In a cluster there is only one Table, but the difference is that exists a unique TimerService active per time, when the node that execute the TimerService fails, another node become the master, therefore doesn't exist timer information exchange between nodes due to the information is available in the database