Transaction manager with In-Memory Derby JobRepository + MySQL DB for data

[Jakub.Kahovec]

Hi,

What are the implications/caveats of using non-JTA TransactionManager, while having JobRepository as an In-Memory DB (H2 or Derby) and having business data in MySQL DB, being read by JpaPagingItemRead and updated by JpaItemWriter ?

Thanks

Jakub

[arno]

Spring Batch can't guarantee the synchronization between business data and batch metadata in case of failure (e.g. the number of skipped items could be wrong). This could happen for corner cases, not on a "sunny day".

[Jakub.Kahovec]

And how about having actually two transaction managers , one for the Spring Batch (in-mem) DB and the other for the business data DB ?

[cnmconsulting]

They should bind to different threads. You can have multiple transaction managers tied into different datasources. Does this clarify your question?

[Jakub.Kahovec]

They for sure will be tied to different datasources, one into the Spring Batch in-mem Derby DB (for job-repository) and the other into the business data DB. But as regards them being bound to different threads, I'm not sure about this one. I don't think I can tell Spring Batch to somehow manage this. Or do they really have to be each in a separate thread ?

[Dave Syer]

There's a rudimentary example of synchronizing 2 database commits in my article in Javaworld (http://www.javaworld.com/javaworld/j...nsactions.html) - it could do with some tweaks but it probably works for simple use cases. Spring doesn't provide a transaction manager that works this way out of the box (mainly because it is buyer beware - you have to be confident you know what you are doing), but all the APIs are there to make your own. As explained in the article, it doesn't give you the full protection of XA, and you need to be prepared for partial failures.