Stuck Tasklet step which contains a call to public method annotated with @Transactional

[janossch]

We have a Tasklet step, which calls a public method of a @Component and that method is annotated with @Transactional attribute.
Why? Because that Tasklet step creates our Spring Content entity in our H2 DB, then saves data into a file which is incoming from a socket connection, then within the very same step updates the previously created entity with some IDs received from the incoming data. We wanted to encapsulate all these within a transaction to have consistent DB and file representation. However as the incoming data could be larger, this Tasklet step could take for a while (even a couple of minutes).

So far we haven't experienced any problems with the above described implementation. So it did its job flawlessly, but just recently we saw that Tasklet steps are getting stuck sometimes in production grade environments. Another factor could be that the system is on a medium load so there are other several jobs potentially in running state.
Stuck means in our case:

• the last log line from that job and on that thread is Executing step: [store-step]
• no visible exceptions in the log which belongs to that job
• the thread seems waiting forever (it is there since weeks)

And I started to worry about this @Transactional attribute, what if we misuse it. Just to give you a rough idea, for around ~500 jobs we had 4 jobs which were stuck at that step.

So I started to look around possible causes and I just came across this comment from @fmbenhassine #5019 (comment)

Quote: it is known that using @Transactional methods with Spring Batch can cause issues

Do you happen to know where I can find more references/documentation/details to this known issue?

Please share any thoughts/tips/ideas on the above! :) Thx!

[fmbenhassine]

Quote: it is known that using @Transactional methods with Spring Batch can cause issues

The "problem" with calling transitional methods within a tasklet is about transaction properties. The tasklet is already executed within the scope of a transaction driven by Spring Batch, so any call to an external method that is also defined to run in a transaction should be carefully considered, specifically the isolation level and the propagation behaviour : should that method participate in the current transaction driven by Spring Batch? or should it start its own transaction with Propagation.REQUIRES_NEW?

There is nothing that prevents you from calling transactional methods from within a tasklet (ie nested transactions), but in that case you need to consider manually handling the nested transaction's behaviour yourself (commit, rollback).

Does this clarify things better?

[janossch]

Definitely! Thank you for the reply!