I added the parameter to the connection string, but the program still encountered the same deadlock.

Here is the new change branch: https://github.com/geiz123/async-batch-test/tree/spring-suggestion

I created a new DataSource bean with the new connection URL and populated it with the metadata tables:
https://github.com/geiz123/async-batch-test/blob/f30f81c052163b0c59e004b079b1d7f333176c61/src/main/java/com/test/AppDataSourceConfiguration.java#L45C2-L64C3

Then let DefaultBatchConfiguration#getDataSource() return:
https://github.com/geiz123/async-batch-test/blob/f30f81c052163b0c59e004b079b1d7f333176c61/src/main/java/com/test/AppConfiguration.java#L219C2-L222C3

Thank you for the update. I tried your sample and I noticed that it works when there is a single flow in the split. (by commenting this line) or by replacing one of the flows with a simple tasklet. So this might be related to the way threads from the pool are scheduled to run and how they acquire connections from the database pool.

Another thing I noticed is that the issue happens even without opening/closing a connection in the reader. Any reason for doing that? FTR, I never had this issue with a regular jdbc reader getting data from a table.

No particular reason for the open/close connection in the reader. I've tried the code with a simple reader that count with an AtomicInteger and the job would still hang.

I'll try replacing one of the flows with a simple tasklet per your suggestion.

yes please, try and let me know.

We use hsqldb in our entire test suite and we did not encounter any issues with it.