CommonJ TimerManager 与 EJB3 TimerService
我必须为 WebLogic 实现一个简单（非集群）计时器，似乎有两个不同的“标准”选项
- Timer 和 Work Manager API (CommonJ)
- EJB3.0 TimerService
有没有人对使用 CommonJ TimerManager 与使用 EJB3 有什么建议WebLogic 10.0 中的 TimerService？
谢谢。
I have to implement a simple (not clustered) timer for WebLogic and it seems there are two different 'standard' options
- Timer and Work Manager API (CommonJ)
- EJB3.0 TimerService
Does anyone have any advice on using the CommonJ TimerManager versus using the EJB3 TimerService in WebLogic 10.0?
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
CommonJ 最初是在 JSR 237 下提出的，该标准于 2008 年被撤回并合并到 Java EE 平台的 JSR 236 并发实用程序中。请注意，这意味着 CommonJ 提议的标准和 API 发生了重大变化。 CommonJ 名称被删除，新包位于 javax.enterprise.concurrent 下，而不是 commonj.timers 和 commonj.work，并且原始类 TimerManager、Timer 和 TimerListener 被替换为不对应的接口/类，包括 ManagedScheduledExecutorService、ManagedTask、托管任务监听器、触发器。
后一个 JSR 236 最近已通过公众审查，因此应该很快就会成为标准。截至 2012 年 11 月，它是纳入 Java EE 7 规范 (JSR 342) 的初步候选者，但这将在 342 最终确定并发布后得到确认。
因此，CommonJ 存在以下问题：
在 Java EE 7 或更高版本中，
比 EJB 3.0 定时器服务更复杂
我建议您使用 EJB 3.0 定时器服务（如果它满足您的需求）。
CommonJ was originally proposed under JSR 237, which was withdrawn in 2008 and merged into JSR 236 Concurrency Utilities for the Java EE platform. Note that this means a significant change from CommonJ proposed standard and API. The name CommonJ is removed, the new packages are under javax.enterprise.concurrent, rather than commonj.timers and commonj.work, and the original classes TimerManager, Timer and TimerListener are replaced by non-corresponding interfaces/classes including ManagedScheduledExecutorService, ManagedTask, ManagedTaskListener, Trigger.
This latter JSR 236 has recently passed public review and, hence, should become a standard soon. As of november 2012, it is a preliminary candidate for inclusion under the Java EE 7 specification (JSR 342), but this will be confirmed once 342 is finalised and released.
Hence, the following problems with CommonJ:
in Java EE 7 or later
more complicated than the EJB 3.0 Timer Service
I suggest you use the EJB 3.0 Timer Service if it meets your needs.
与 CommonJ Timer Manager 相比，EJB 3.0 中的 TimerService 有一定的限制。例如，它需要样板代码和特定于容器的配置来实现灵活的任务调度。通过在 EJB 3.1 中引入 @Scheduled 注释，这一过程得到了简化。
如果您坚持使用 EJB 3.0 并且需要轻松灵活地配置任务调度，CommonJ Timer Manager API 是一个可行的选择。
此外，Spring Framework 中的任务调度程序 (org.springframework.scheduling.TaskScheduler) 在抽象计时器管理器 API 方面做得很好，并允许使用 cron 表达式进行声明性配置。
TimerService in EJB 3.0 is somewhat limited as compared to CommonJ Timer Manager. For example, it requires boilerplate code and container-specific configuration to implement flexible task scheduling. This was simplified with the introduction of @Scheduled annotation in EJB 3.1.
If you are stick with EJB 3.0 and need easily and flexibly configurable task scheduling, CommonJ Timer Manager API is a viable option.
In addition, Task Scheduler from Spring Framework (org.springframework.scheduling.TaskScheduler) does a good job of abstracting Timer Manager API and allows declarative configuration using cron expressions.
是的，如果 TimeService 功能满足您的要求，请使用它 - 它是 Java EE 标准的一部分！如果不是绝对必要，为什么要使用另一个库。
Yes, if TimeService features cover your requirements use it - it's part of the Java EE standard! Why use another library if not absolutely necessary.