> Now, I have a pretty simple unit test that results in a deadlock: > - one thread is inserting records in a table (in transactions of N=200 records) > - another thread comes from behind and reads the same records (select > * where id > $lastReadID) > > After examining the deadlock trace the explanation is could be this: > - the insert thread has a bunch of X row locks and tries to escalate > to an X table lock > - the select thread has a pending S row lock and tries to escalate to > an S table lock
Are you sure you are escalating to table level locks? The table level escalation threshold is configurable, but should default to 5,000 rows: http://db.apache.org/derby/docs/10.2/tuning/ctunoptimz26019.html#ctunoptimz26019 If your transaction(s) are only touching 200 records at a time, it doesn't seem like you ought to be escalating to table level locks. > Here is the trace I was talking about: In the trace that you posted, I don't see any evidence of a transaction holding or requesting a table level lock. The "IX" and "IS" locks are *intent* locks, which is not the same thing as a table level lock. thanks, bryan
