The fourth installment of Monson-Haefel's Guide to Enterprise JavaBeans, 'EJB 2.1: The Timer Service', has been posted. This article describes the EJB Timer Service API, its use with entity, stateless session, and message-driven beans, and provides some criticism and suggested improvements of the Timer Service.

Read Richard Monson-Haefel's 'EJB 2.1: The Timer Service'

The same serious deficiency is in the JMX timer service. It is really painful to implement some real world use cases with millisecond based interval timer. Your code is soon full of various calendar and timer related management. I hope the spec team adds a cron like functionality to both timer services ASAP. Meanwhile, it might be a nice open source project?

Monson-Haefel constantly writes books and papers on J2EE stuff. I wonder, how much he actually develops with J2EE? Aren't his books pure theoretical textbooks?

I actually studied EJB with his first book. I liked it at that time 3 years ago. But since then, after implementing several J2EE projects, things look very different to me now.

Here is a sample of Monson-Haefel's work.

Does anybody really use any of the "middleware" power of J2EE as prescribe by Sun's blueprint? I am talking about security, transaction, deployment. What I've seen in serveral company is just a big mess of Struts/JSP, a bunch of Struts Actions doing the same processing over and over with no caching, a bunch of JavaScript mixed in. None actually use EJB because "it's easier to go to the database directly, we'll do that in the next phase". There isWeblogic app servers, and that makes it J2EE :).

But no matter, Mr. Monson-Haefel can really explain these stuff better than anyone else. Thank you very much and keep writing. If these stuff is any good, someone will get it and make good use of it.

I hope the expert group adopts the cron-like scheduling facilities since it is not hard (as Richard explained.)

I think Richard's cron-like-syntax solution lacks internationalization support. Perhaps it should be better to use a more OO approach creating a Schedule interface that encapsulate informations the timer service need to perform its operations.
Then you can create classes that implements this interface like a GregorianSchedule in which you can set fields like month, day of the week, etc. in a way similar you do in a Calendar.
If you like cron-like-syntax you will be able to subclass it and define a constructor that accept a String or, better, you can write a CronScheduleFormat that knows how to convert between a cron-like String and a Schedule object and back.

Cron is attractive because it's familiar (to some), but not very intuitive or porttable as you said. Rather than

timerService.createTimer("23 * * * 1,3", start, end, null);

I'd rather see calls like

timerService.createTimer(TimerService.EVERY, TimerService.MONDAY | TimerService.WEDNESDAY, ...);

timerService.createTimer(TimerService.NEXT, TimerService.WEEKDAY, ...);

timerService.createTimer(TimerService.EVERY, TimerService.MONDAY | TimerService.WEDNESDAY, ...);

etc.

how does the Timer Service behave in the clustered Env?
how to use it to schedule a batching job, for example of Database cleanup,
it is not acceptable to run multiple times for the same job in different
clustered instance.

Job schedulers, J2EE

https://www.theserverside.com/resources/article.jsp?l=Job-Scheduling-In-J2EE-Applications

http://sourceforge.net/projects/quartz/

http://clockwork.sourceforge.net/

http://www.simscomputing.com/products/flux/

http://www.acelet.com/super/SuperScheduler/index.html