我在我的应用程序中使用EJB 3.0 Timers
。
关于EJB Timers的一件事是它们默认是持久性的,这意味着当服务器重新启动时,将自动调用Timers而不再调用它们。
我要求在重新启动服务器时手动启动这些计时器。为此,我知道我们需要在配置XML中更改一些我不确切知道的属性。
我在哪里需要更改属性以设置persistent = false。
我正在使用Weblogic Server。
在EJB 3.0中,定时器是持久的,并且没有要设置的属性使它们成为非持久性的。 EJB 3.1 TimerConfig可能会影响到这一点。此外,WebLogic特定的configuration不提供任何帮助。
TimerConfig timerConfig = new TimerConfig("some info ...", false);
timerService.createIntervalTimer(3000, 1000, timerConfig);
@Schedule(hour = "*", minute = "*", second = "*", persistent = false)
private void myScheduledMethod(Timer timer) {
// ...
}
为此,您需要使用EJB 3.1或更高版本,这意味着您需要Java EE 6(或更高版本)服务器或支持此ejb版本的容器。对于Weblogic,至少需要使用12cR1版本。
@PreDestroy
方法中取消。我希望,我可以帮忙。
这个帖子已经过时了,但我认为这些担忧现在仍然适用。自EJB 3.1以来,有一个属性用于指定EJB持久性,正如@mikko-maunu所指出的那样,但我认为它的建模有两个职责:
我认为上面的概念应该是独立建模的,因此我们可以将EJB计时器存储在数据库中,并且还可以更好地控制在系统重新初始化时如何处理失火的触发器,即应该重新触发或忽略它们。
否则,基于EJB Timer的作业模块看起来很尴尬,其中一些存储在数据库中而另一些则不存在,只是因为我们不想为过于频繁安排的作业重新启动以前错过的触发器,每小时运行一次例如,基础。
我注意到,在JBoss 7.1 / Java EE 7中,将调度信息保存在数据库中可能会支持集群配置的集中控制,而不是具有非持久时间调度的重复和独立实例。但是,对于每天触发多次的工作而言,这种附带效应是,在系统重新初始化时,所有偶然失效的触发器都会立即被触发。
为了在重启时更好地控制持久性EJB Timer,我们可以在@PostConstruct方法中检查计时器的getNextTimeout()
是否是过去时间。如果计时器应忽略失火的触发器,我们可以使用相同的scheduleExpression取消旧计时器并立即创建一个新计时器,因此只考虑将来的触发器。这似乎对计划每天运行多次的计时器非常有用。
另一种可能的,可能更简单的方法是,在@Timeout方法中,检查计时器的下一个执行时间getNextTimeout()
是否在当前日期和时间之前,然后确定是否应该处理或丢弃先前的错误触发器。