views:

1363

answers:

6

I'm trying to learn Spring Batch, but the startup guide is very confusing. Comments like

You can get a pretty good idea about how to set up a job by examining the unit tests in the org.springframework.batch.sample package (in src/main/java) and the configuration in src/main/resources/jobs.

aren't exactly helpful. Also I find the Sample project very complicated (17 non-empty Namespaces with 109 classes)! Is there a simpler place to get started with Spring Batch?

+1  A: 

Before you jump on the Spring Batch wagon, you may want to read what SO's own cletus has to say about its shortcomings:

http://www.cforcoding.com/2009/07/spring-batch-or-how-not-to-design-api.html.

I recently evaluated Spring Batch, and quickly rejected it once I realized that it added nothing to my project aside from bloat and overhead. Spring Batch may eventually become an OK product (much like EJBs got it right this time around), but at the moment it looks suspiciously like a solution in search of a problem.

rtperson
I've already read it. It does seem like it will be useful for what I'm trying to do (and for architecture reasons I'm having to use Spring anyway). However I worry about the complexity (awful complex configuration files). In short, I'm still evaluating it myself, which is why I asked the question.
C. Ross
@C. Ross - It's perfectly possible to use Spring in combination with Quartz (for scheduling) and avoid Spring Batch altogether. You can use a strategy pattern to generalize jobs and steps, and you can easily roll your own persistence by storing transactional states on your data. That's what we ended up doing, and it's working out fine. I just don't see Spring Batch offering anything of value to compensate for its headaches.
rtperson
Batch systems can be much more than just steps and jobs. If that's all you need, then fine, but if you need additional functionality such as repeat and retry functionality, parallel processing, etc then Spring Batch may be a good solution.
Steve
+1  A: 

I agree that the user guide is very confusing (compared to the Spring Core user guide at any rate). It doesn't adequately address some very important gotchas that you will run up against in any moderately complex batch scenario.

Important things that you should drill down into as a new starter, and decide your requirements for are,

  • configuration of exceptions (when to skip, when to fail, when to retry)
  • use of execution context to maintain state (eg when to use step execution context vs job execution context).
  • general maintenance of state (use the step scope, especially for input parameters)

It is worth persevering however. Batch programming is very different to other server side styles and greatly benefits from the usual Spring "pattern abstraction" approach.

Caoilte
A: 

I've just started looking at Spring Batch as a possible replacement to our in-house batch framework. Actually creating a batch server with the capability to schedule Jobs and a JMX interface on top to provide an overview of running/previously ran job instances has taken little more than a day. However, like Caoilte, I am finding problems with the documentation. The main one, and one which isn't in the documentation or the javadocs, is what tables are required by the JobRepository. The default is to have a database-persistence JobRepository, which is one of the requirements of my new server, but I cannot find any mention of the tables required. I've had to search Google high and low for any mention of them (If they are in the documentation, then I will gladly put salt on my humble pie).

I think actually creating a batch to run within Spring Batch is a rather complex task, given the vast array of configuration options available to you. This is a strength in my eyes. It provides opportunities to configure complex batch tasks in xml, which I have yet to find in any other batch framework (that I know of). But if you really did not want to harness the power of Spring Batch, why not just create a job with a single tasklet step (But then you have to ask yourself if its worth the overhead).

Richard
I abandoned the framework because of the limited documentation, and because to be honest, it's much more than we needed. Good luck.
C. Ross
A: 

Too bad you guys abandoned it, the framework is actually really great. But if anybody else needs a quick start try: Spring Batch Quick Start

/Anatoly

litius
+1  A: 

I recently gave Spring Batch a real try. I'll say that in my implementation, I used an in-memory repository (because restarts and retries were not a priority in my project's circumstance), but I can appreciate what Richard says about the JobRepository: you basically have to dig deep to find the database schema.

For Spring Batch 2.1, they do provide some documentation on the repository: http://static.springsource.org/spring-batch/reference/html/metaDataSchema.html, including discussions about how to deal with database-specific implementations. The DDL for creating the tables are located in the core Spring Batch JAR file:

spring-batch-core-2.1.0.RELEASE.jar:/org/springframework/batch/core/*.sql

Scripts are present for DB2, Derby, H2, HSQLDB, MySQL, Oracle 10g, PostgreSQL, MS SQL, and Sybase.

WineSoaked
Another observation about Spring Batch: I can appreciate people's sentiments regarding the API: it does appear heavy-handed at first glance. But it provides enough goodness when dealing with processing flat ASCII files (and you'd be surprised how much legacy data processing still uses fixed-width flat files -- heck, just the amount of COBOL still in use sometimes makes my head hurt) that I decided to give it a try.My last thought is that the notion of Job and Step execution contexts are what tripped me up again and again in development.
WineSoaked
@WineSoaked You can edit that comment into your question. But what you say makes sense. I have to deal with the ASCII files produced by COBOL too, so maybe I'll take another look at it. I still have the vague feeling that it's overkill though.
C. Ross
Yeah, this was my first ever answer (and comment) on SO, so the mechanics of editing were not clear to me (as they are now).
WineSoaked
Thanks @WineSoaked for saving me the trouble of digging for the DDL scripts :D
Eran Harel