JBoss 7.1.1和EJB 3.1 Timer服务 [英] JBoss 7.1.1 and the EJB 3.1 Timer Service

查看:106
本文介绍了JBoss 7.1.1和EJB 3.1 Timer服务的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在考虑将基于Spring Quartz的应用程序移植到EJB 3.1,以查看EJB是否有所改进。我在理解故障转移如何与Schedule Timer Service一起工作时遇到问题。在Quartz中,有集群Quartz实例使用的数据库表。如果群集中的一个节点崩溃,则作业仍将在其他节点上执行。

I am thinking about porting a Spring Quartz based application to EJB 3.1 to see if EJB has improved. I am having problems understanding how fail-over works with the Schedule Timer Service. In Quartz, there are database tables which clustered Quartz instances use. If one node in your cluster crashes, jobs will still get executed on other nodes.

我一直在研究Timer服务如何持久化事物,它似乎使用了创建Timer的服务器的文件系统。这是真的?我不知道这怎么可能,因为它将不支持故障转移,从而使计时器服务不可用。

I have been looking at how the Timer Service persists things and it appears to use the file system of the server the Timer was created on. Is this true? I do not see how this would be possible as it would render the Timer Service unusable since it would not support failover.

所以我一定很想念东西。谁能帮我这个忙吗?

So i must be missing something. Can anyone help me out with this?

推荐答案

EJB计时器服务根本不如Quartz(带有或不带有Spring)先进。

The EJB timer service is simply not as advanced as Quartz (with or without Spring).

EJB计时器被保留到未知位置。它可能恰好是文件系统,但如果恰好在Windows上运行,也可能是Windows注册表,或者它可能是LDAP服务器或其他任何东西。

EJB timers are persisted to an unknown location. It may happen to be the file-system, but it could also be the Windows registry if you happen to be running on Windows, or it could be an LDAP server or whatever.

EJB规范JIRA上存在一个与此有关的问题已有一段时间,并且在规范邮件列表中进行了讨论,但是由于没有人打扰任何人(也许是因为很多人当时在度假)。如果您要问我,这是解决问题的最无聊的理由之一,但我想规范主管有时必须诉诸此类措施。

There was an issue on the EJB spec JIRA for some time about this, and it was discussed on the spec mailing list, but then it was brutally dropped and closed because no one bothered to reply anyone (perhaps because a lot of people were on vacation at the time). It's one of the lamest reasons to close an issue if you'd ask me, but I guess the spec lead sometimes must resort to such measures.

无论如何,在JBoss AS中持久发生在嵌入式关系数据源上,该数据源又将其写入文件系统。通过专有配置,您可以将此数据源指向任何远程DB。故障转移也必须来自专有的JBoss功能。尽管EJB出于潜在的集群目的禁止了很多事情,但是规范中没有明确的集群支持,因此EJB计时器特别不支持集群。

Anyway, in JBoss AS persisting happens to an embedded relational datasource, that on its turn writes to the filesystem. Via propriatary configuration you can point this datasource to any remote DB. Fail-over would have to come from propriatary JBoss functionality as well. Although EJB forbids lots of things for the sake of potential clustering, there's no explicit clustering support in the spec and thus specifically EJB timers are not cluster aware.

这篇关于JBoss 7.1.1和EJB 3.1 Timer服务的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆