0

I'm working on a Spring Batch application that was running into a DB2 deadlock while using a default JdbcCursorItemReader. When the batch job ran into an error, we had set up a SkipListener to write an "Error" status to the relevant row, which is when the deadlock occurred.

We found that by using a default JdbcPagingItemReader, we were able to avoid the deadlock scenario, though we aren't exactly sure why this is the case.

My understanding of Spring Batch is that either Reader should have freed up the lock on the database once the ResultSet was read in from the query, but this didn't appear to be happening with the JdbcCursorItemReader.

Would anyone be able to help me understand why this is the case?

Thanks!

KAM1KAZEKOALA
  • 115
  • 1
  • 2
  • 6
  • 1
    This is probably related to the JDBC driver of DB2 (Not a Spring Batch issue). I invite you to read the comments in https://jira.spring.io/browse/BATCH-1273 (even though it talks about XA which is probably not your use case, but it is still related). "Cursors are just a bad idea on some platforms." as mentioned by Dave Syer. – Mahmoud Ben Hassine Nov 22 '18 at 08:51

1 Answers1

0

The JdbcCursorItemReader will maintain a position (Cursor) within the database so it knows where to read from next. This Cursor is maintained by a Lock. The JdbcPageItemReader appears to be submitting queries requesting data from a known start and end point such that it only reads the data between these two points and does not require locks between calls.

Quentin Presley
  • 1