Announcement Announcement Module
No announcement yet.
Spring Batch standalone-Server / architecture? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Batch standalone-Server / architecture?


    we're planning a project using Spring Batch. Core of this project is a batch server being capable of handling a medium number of concurrent jobs (~20). Furthermore there should be a cronjob-like management of jobs. One very important aspect is monitoring, owner notification (E-Mail) and controlling jobs resp. their execution.

    There a now some questions...

    1) From the point of stability and performance, is it better to write your own server application or using a J2EE Container (would Tomcat suffice)? I'm scratching the old topic about using Spring Batch as controller application, where each job could be a (servlet) thread... but maybe you find some better pros/cons (e.g. JMX console, interface to display available jobs, ..)?

    2) What kind of scheduler is the preferred solution - should I use Quartz or does Spring Batch come with its own scheduling system?

    3) Would kind of architecture / system would you suggest in order to be able to "deploy" new jobs through a web interface? What about class loading issues? Are there sophisticated notification mechanisms available in Spring that I could use?

    4) I read this thread and noticed that Spring Batch 2.0 has been released. Dave Syer gave some hints their, but I assume they are valid for version 1.0 of Spring Batch. Could you point out what would be different with 2.0?

    Thanks thanks thanks!

  • #2
    1. I'm sure tomcat could handle 20 concurrent jobs. Not clear what you would get from a more heavyweight server. I wouldn't necessarily want to have jobs running in a servlet request thread though - better to background it and return a token to the caller (like a JobExecution).

    2. Quartz is an option. Spring Batch does not have a scheduler. Spring Integration does, and this is actually moving to the core Spring Framework in Spring 3.0. I would use that if Spring 3.0 is an option (and we can make Spring Batch 2.0.x work there as well).

    3. This is tricky, and the servlet container doesn't help you. It seems to me that you have no choice really but to deploy all jobs, or maybe groups of related jobs, in a single WAR file. SpringSource dm Server is really the deployment model that we need for this problem.

    4. The only relevant change in 2.0 is that there is now a stop() protocol (wrapped in the JobOperator).