WAR版本更改后运行EJB持久计时器

Question

我有一个应用程序，它以独立模式在Wildfly-18上运行持久定时器。这些仅仅是由Timerservice触发的。

@Stateless
class MyTimerService {

    @Resource
    private TimerService timerService;

    public void registerTimer() {
        TimerConfig timerConfig = new TimerConfig("identifier", true);
        timerService.createSingleActionTimer(executionDate, timerConfig);
    }

    @Timeout
    void timeoutTimer(Timer timer) {
        // Do stuff
    }
}

在本质上，这是很好的工作，直到一个新的发行版。这是因为在他们的文档中说明了以下几点

持久计时器将由EAR的名称、子部署JAR的名称和Bean的名称来标识。如果其中一个名称被更改(例如，EAR名称包含一个版本)，则计时器条目成为孤立项，计时器事件将不再被触发。

因此，在新版本之后，data文件夹中将有一个新文件夹。但老定时器是孤儿，不再被处决。

wildfly-18.0.1/standalone/data/timer-service-data
├───my-application-1.0.0.my-application-1.0.0.MyTimerService
│       6a14484b-3a62-4345-bcc2-1507ca9b6223.xml
│
└───my-application-1.0.1.my-application-1.0.1.MyTimerService

看起来，您只能更改顶层文件夹(timer-service-data)，查看模型-参考。但事实上，每一个新版本都将是一个新文件夹。

我们希望将版本号保留在war中。是否有方法在新版本发布后继续引用同一个文件夹？还是运行旧的孤儿计时器？

Answer 1

持久计时器只有在服务重新启动时才是持久的，而不是在代码库重新部署下(特别是在工件版本更改下)。

来自文档

另外，请注意，EJB持久计时器与基于应用程序名称、模块名称和bean名称的EJB相关联。如果更新了一个应用程序，并且这些名称都发生了变化，那么定时器将继续存在于数据库中，但由于不再过期并运行，计时器似乎不再存在。

我的建议是，您将任何基础设施状态视为易失性的(除文件系统、数据库等特定持久状态外).以及对其进行安全状态管理)。

对于这种特殊情况，当系统重新启动时，您可以检查哪些Timers被搁置，然后再次重新配置它们，但是，我的建议是使用特定的排队策略(例如，在某些*MQ中使用优先级队列)。这将使它对服务故障具有弹性，它可以并行地、以分布式方式处理、自动缩放等等.