the logic is slightly different dependent on isolation level, what isolation level are you running. All the code gets the table level intent lock first, and if that succeeds then checks if it has covering locks such that it does not need to get row locks.
The code is in the lockContainer() routines in opensource/java/engine/org/apache/derby/impl/store/raw/xact/RowLock*.java. Bryan Pendleton wrote:
I ran the following experiment, with somewhat surprising results: create table a (a integer); autocommit off; lock table a in exclusive mode; select * from syscs_diag.lock_table; insert into a values (1); select * from syscs_diag.lock_table; -- Note (1) below commit; select * from syscs_diag.lock_table; lock table a in exclusive mode; select * from syscs_diag.lock_table; update a set a=2 where a = 1; select * from syscs_diag.lock_table; -- Note (2) below commit; quit; At points (1) and (2) in the above script, I was surprised to see that Derby had taken out additional IX-mode locks on table A. It seems that Derby is smart enough to know that it doesn't need to take out ROW locks, since I have the table locked exclusively, but that same optimization doesn't seem to be performed at the table level, and the (apparently) unnecessary IX-mode table lock is redundantly acquired. Am I overlooking something? Is there a reason for the extra IX-mode lock to be taken? Or is this just an opportunity for an additional optimization? thanks, bryan
