This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Can you check that your caller is not within a transaction when the job is launched? If your caller (for instance a unit test with the Spring test infrastructure) has a transaction, then what you are experiencing is normal since Spring Batch defines REQUIRED transaction demarcation (i.e. if a transaction exists, use it; if not, create one).

One way to avoid this is to have a custom facade in front of the Job launcher with a transaction demarcation NEVER. That way, a caller that is within a transaction won't be able to start the batch. I wouldn't rely on a job launcher that spawns a new thread as transaction managers are capable of detect that and propagate the transaction context in the created thread.

Comment

I have a step with commit size of lets say 50, internally the item writer implementation calls a home made service (made with hibernate). My goal is to be able to split the transaction size in case of a failure, lets say that it failed inserting 50 transactions then try with 2 chunks of 25 items and so on, until i commit everything except the record that has issues.

Is that doable?

Comment

When the chunk is about to start, a new transaction is created. Say your chunk size is 10, the reader will be called 10 times, the processor will be called 10 times and the writer once with the 10 elements returned by the processor. Then the commit will occur (Spring Batch will also contribute some metadata to the step execution context).

This is explained in the documentation.

What you are describing is already provided out-of-the-box by Spring batch but not with the granularity you would expect. When something fails in the writer, it has no idea which item in the list caused the issue so, if the exception is recoverable, it will treat all elements of the chunk again one by one (i.e. with a chunk of size 1).

In practice, it is better to perform as much as possible in the reader/processor because if something fails there we know exactly what went wrong.

Comment

"When something fails in the writer, it has no idea which item in the list caused the issue so, if the exception is recoverable, it will treat all elements of the chunk again one by one (i.e. with a chunk of size 1)"

So if a no-rollback exception happens spring batch will automatically generate X number of transactions to write 1 item at a time? Where can i read more about this? i think im looking in the wrong place because i dont find much info about it.

Thanks

Comment

Most users don't need to know about the internal details of retry semantics, so the user guide doesn't cover it in much detail - you have to go to the source code (FaultTolerantChunkProcessor). If you want more you can look at the upcoming books (Spring Batch in Action definitely covers it), or make a JIRA request for the user guide to be updated (community contributions gratefully accepted).