A deadlock occurs when concurrent transactions hold locks that the other transactions need. Each transaction waits for a lock release, so none can proceed. Databases may detect the cycle and abort one transaction immediately, or terminate one after a timeout; the surviving transaction can then continue. section 11.2.4
Opposite update order
One transaction updates Item 1 and then Item 2, while another updates Item 2 and then Item 1. Hibernate flushes the changes as SQL updates, leaving each transaction holding one row lock while waiting for the other. The database may abort one transaction. section 11.2.4
Reduce the probability or scope of deadlocks by:
- Ordering updates by primary key so concurrent transactions acquire row locks consistently; Hibernate supports this through the hibernate.order_updates persistence-unit setting. section 11.2.4
- Using serializable isolation when updating a single row should make concurrent work wait on the table rather than interleave conflicting row locks. section 11.2.4
- Acquiring exclusive locks when selecting data so competing transactions wait until the locks are released. section 11.2.3 section 11.2.4
- Treating deadlock handling as an operational concern: light testing may miss cycles that appear under production transaction load, and aborted transactions are difficult to recover from in application code. section 11.2.4
