CommonJ TimerManager versus EJB3 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开发者_StackOverflow TimerManager versus using the EJB3 TimerService in WebLogic 10.0?

Thank you.

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:

• it is not and will not be a Java standard, until significantly changed under JSR 236 which will be included in Java EE 7 or later
• it goes beyond your requirements, presumably, and is more complicated than the EJB 3.0 Timer Service

I suggest you use the EJB 3.0 Timer Service if it meets your needs.

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.

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.