Spring alternative to TimerService in EJB 3

Question

We're using EJB TimerService:s for controlling tasks that needs to be executed on demand or triggered via a cron expression some will run every night e.g. statistic collectors and some will run every 10s e.g. checking for new orders needed to be processed we must also be able to turn them on and off. It works fine most of the time but sometimes the the processes cannot be stopped and the only way to fix the problem is to flush the TimerPool and redeploy the application.

I have been looking for a another solution of our problem and we have tried a version, with more controlling functionality , of the example below: http://www.adam-bien.com/roller/abien/entry/legally_starting_threads_in_ejbs

It works fine but I've got the feeling we're pretty close to the boundary of how you should work with EJBs.

I have been looking a Task Execution and Scheduling: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/scheduling.html

And it seems like a way to get rid of the EJB:s since we're only using them for the TimerService and the communication between the controller and the actual task.

The problem is that I need more control than static configuration files and perhaps home brewed SchedulerFactoryBean would work but I don't really know where I should start looking?

Type of jobs

ProcessEngine

• Will be executed every 10s and check if there are any new customers and process their orders
• Should be able to turn the engine ON and OFF, either with soap or via a setting in the DB

StatisticsCollector

• Should run every night at 3am by default
• Should be able to be triggered to run right now on demand

Answer 1

From the comment above, I'm guessing that you need a far more complex scheduler. Have you thought about using Quartz Scheduler?

It's open source, extendable and quite powerful. Scheduling is done via CRON expressions, which can fill the needs specified in your post

The disadvantages to Quarts in comparison to EJB is that out of the box, scheduled jobs are not persistent, it creates its own threading pool (which can't be resized at runtime), and there is no fairness to it's threading algorithm (i.e. if a job hasn't fired at its assigned time due to starvation, it gets scrapped). Still, I've had good experiences with Quartz as a whole.