db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Pendleton <bpendle...@amberpoint.com>
Subject Re: lock escalation and deadlocks
Date Wed, 01 Aug 2007 04:18:06 GMT
 > 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


Mime
View raw message