In another thread I requested a recommendation for something akin to a Windows service and someone suggested using MDBs with queues. I'm still not too sure about that process nor how it works (limited J2EE experience and very much so with MDB)
In the meantime I found out about the Timer Service feature addition in EJB 2.1. This pretty much fits the bill of what I need--I can have some functionality called upon regular intervals.
Basically I'm going to have many physical locations running my system and want them to update each peer on regular intervals with all new records and without using human interaction or external programs (cron, scheduling systems).
I think (?) I can have the timer service callback the main service bean (CMP) every few hours and have it update its peers (the other installations) with some data transfer method (not sure about that part yet).
I'd like to hear some feedback from you mature J2EE developers about this idea. Do you think its properly designed? I've found a newer article on timer service at ONJava but most other articles are dated and have weary advice from 2 years back. They claim that Timer Service is low priority in the J2EE application server so not to rely on it
Is it reasonable to assume most application servers now support the EJB 2.1 spec and have timer service available? Are there other alternatives? (NOT running external scheduler... I hate that idea, should be self-suficient system for this particular task) [ December 24, 2004: Message edited by: Steve Buck ]
Joined: Nov 23, 2004
I'm still researching up on the Timer Service. Hopefully others have used it already.
Now the main question I have about it--should you rely on it for business operations (and not just simpleton things such as cleaning up the database or some such)? Can you assume it will always have at least an average (minimal) priority? I can't seem to find any documentation on upping the priority of it
Hi Steve, I used EJB Timer Service a few months back, with JBoss 4, and it almost (see furher) worked very well. The system had to start a process at repeated interval to get some data through HTTP (in XML format) and persist these data in database. The only problem I had is that I was not able to set a timeout for this operation, because EJB Timer Service has no such things and that thread management is forbidden in EJB container. In this particular case the timeout was mandatory, or else an HTTP connection could remain open forever (because I cannot trust the remote servers to be always up). This is the only reason I finally moved this feature to the servlet container. Hope it helps.
Bruno Collet<br /><a href="http://www.practicalsoftwarearchitect.com" target="_blank" rel="nofollow">www.practicalsoftwarearchitect.com</a><br />- The Paradox of Software Architecture: It is easy to make a complex architecture, but it is difficult to make a simple architecture.
hi Steve.. Ive done a project using the EJB Timer Service...let me tell u whats its like...although being an addition to the EJB specs..it performs the basic things that u need to launch a process or even trigger an event when the timer expires...it all depends on the nature of the application that ure developing..and bear in mind that u cant use the Timer Service with stateless beans (which is quite a bit of a drawback) at a first glance, its fair enough to use it for an application that has a specific functionality...but if ure gonna build something thats later going to expand or would demand scalability and other features, u might look at the Quartz Crystal API ..the flexibility that it gives you is far much better than timer service in EJB. Job Scheduling in Java by Bosanac, D.
Best Regards Aboo
Joined: Nov 23, 2004
Thanks for the feedback!
Bruno Collet: you point out some important shortcomings with this approach. Unfortunately I'll need to do some pretty complex stuff with the Timer Service so it is most likely not appropriate for me :/
How exactly did you move the feature to the servlet container? I'm not sure I follow that part. Does the servlet container support the use of threads?
Aboo Bolaky: for what I'm doing I only need to do callbacks on entity bean methods. Quartz Crystal API may be pretty slick, but I can't use it. [Unfortunately] I kind of made a choice that when doing any J2EE I will avoid add-ons that are not part of the J2EE spec. Its limiting and frustrating but just something I'll have to deal with :/
Is there any hint of EJB future specification allowing for threading?
Originally posted by Aboo Bolaky: and bear in mind that u cant use the Timer Service with stateless beans (which is quite a bit of a drawback)
I haven't used the Timer Service, but I just started reading the spec on it and wanted to correct this. It is stateful session beans that cannot be used with the Timer Service, which makes sense. From the spec (22.2 page 494):
Timers can be created for stateless session beans, message-driven beans, and entity beans. Timers cannot be created for stateful session beans.
With regards to this discussion, the top of the same page says
While timer durations are expressed in millisecond units, this is because the millisecond is the unit of time granularity used by the APIs of the J2SE platform. It is expected that most timed events will correspond to hours, days, or longer periods of time.
I read this as "don't count on accuracy to anything smaller than an hour, probably one minute in practice." [ January 11, 2005: Message edited by: David Harkness ]