can it support a database with no transactions?

[struesda]

Our core database we are looking to implement Spring Batch on a database with no transactions (Informix).

Is it possible to customize the transaction handling in Spring Batch so we can avoid sending COMMITS/ROLLBACKs to the database and getting errors back - and do our own manual actions instead?

Also - is nested transactions support required? Informix does not support these at all.

[lucasward]

Technically, you can pass in any kind of PlatformTransactionManager to the StepExecutor you want. However, if you have no transactions then any errors whatsoever will require your entire batch job to shut down and could leave output in an inconsistent state. (which is the motivation behind transactions in the first place) I'm not familiar with Informix as a database, but I can't imagine why it wouldn't support transactions, or why you would want to run any type of application without transactions. The only use case I can think of is a pure file to file batch job. In this case, you could 'turn off' the repository, which would then not require any database. However, keep in mind that doing so would prevent you from seeing any status on the job, or restarting it.

[struesda]

I can't imagine it without transactions either / but that's the legacy system we have. We are told that if we turned transactions on - with no code changes - then it would slow performance by 200-300%. All of the existing code is single threaded. One of the reasons we want to port to Java is to take advantage of a multi-threaded architecture. But we still need to integrate the existing platform as we move along.

[Dave Syer]

Coincidentally Spring Batch does actually include a "dummy" transaction manager (ResourcelessTransactionManager) that could be used to make the database access non-transactional as a side effect. It was intended (and is used internally) for testing purposes.

[kdelong]

Would you use ResourcelessTransactionManager if you are only doing a file-to-file step? Otherwise what transaction manager would you install in SimpleStepFactoryBean?

[lucasward]

Even if doing File to File, I would still want a normal transaction manager and repository, because then you can see output in the status tables. However, if you don't care about the meta data, then you could just use the 'in-memory repository' that's covered in chapter 4:

http://static.springframework.org/sp...n.html#d0e2862

[kdelong]

So if you were doing a job with File input and File output, what PlatformTransactionManager subclass would you configure for the job? There doesn't seem to be a Spring implementation that's not coupled to a DB, JMS, or some other resource provider.

Would you hook it up to the transaction manager for the batch database that stores the job executions etc?

[dkaminsky]

Just as Dave suggests, the ResourcelessTransactionManager will fill this void. You can inject it and it doesn't do any transaction management. In terms of side effects, the really important thing to remember is that even if it doesn't break your file-to-file operations, updates to your Spring Batch metadata will not be protected, so you can actually have jobs break as a result.

Spring's transaction support is pretty interesting - it handles a lot of concerns for you, including whether or not nesting is supported - you should read up more about it directly from the Spring documentation:
http://static.springframework.org/sp...ansaction.html

[kdelong]

My question was, when I have a Job that deals only with files, which impl should I pick? I have a txMgr for the batch meta data database, but it seems silly to hook that one up to the one that manages the file. Or is it?

Between Spring 2.5.2 and Batch, I have these impls:
CCI, DataSource, Hibernate, JDO, JMS, JPA, JTA, Resourceless, TopLink, WebSphere.

The only one that makes any possible sense is Resourceless. My question was just to confirm that that is the intent of the framework developers.

[Dave Syer]

You should probably use the DataSourceTransactionManager if you are using the Jdbc*Daos from Spring Batch (i.e. with any "normal" database platform and with JobRepositoryFactiryBean, as in the samples). Just because your business data is file-based, doesn't mean that you shouldn't use a database for the batch meta data - generally the opposite is true. There might be some special cases where you can live without an RDBMS for the meta data (e.g. if you really don't care about restartability or reporting and tractability), but that won't often be the case.