From a7bd2db6184ff809ba0da235ab91b22edee3da97 Mon Sep 17 00:00:00 2001 From: unknown Date: Thu, 12 Aug 2004 13:38:10 +0300 Subject: This change includes optimization for a lock wait rules and a new behaviour for a REPLACE command. innobase/lock/lock0lock.c: Gap type locks without LOCK_INSERT_INTENSION flag do not need to wait for anything. This is because different users can have conflicting lock types on gaps. innobase/row/row0ins.c: The manual defines the REPLACE semantics that it is either an INSERT or DELETE(s) for duplicate key + INSERT. Therefore, we take X-lock for duplicates. --- innobase/lock/lock0lock.c | 36 ++++++++++++++++++++---------------- 1 file changed, 20 insertions(+), 16 deletions(-) (limited to 'innobase/lock') diff --git a/innobase/lock/lock0lock.c b/innobase/lock/lock0lock.c index 2ace0822a82..2d326f7392f 100644 --- a/innobase/lock/lock0lock.c +++ b/innobase/lock/lock0lock.c @@ -758,10 +758,10 @@ lock_rec_has_to_wait( lock_t* lock2, /* in: another record lock; NOTE that it is assumed that this has a lock bit set on the same record as in the new lock we are setting */ - ibool lock_is_on_supremum) /* in: TRUE if we are setting the lock - on the 'supremum' record of an index page: we know - then that the lock request is really for a 'gap' type - lock */ + ibool lock_is_on_supremum) /* in: TRUE if we are setting the lock + on the 'supremum' record of an index + page: we know then that the lock request + is really for a 'gap' type lock */ { ut_ad(trx && lock2); ut_ad(lock_get_type(lock2) == LOCK_REC); @@ -773,15 +773,15 @@ lock_rec_has_to_wait( /* We have somewhat complex rules when gap type record locks cause waits */ - if( lock_is_on_supremum && !(type_mode & LOCK_INSERT_INTENTION)) - { - /* Lock on the supremum record is really a 'gap' type lock - and gap type lock do not need to wait if it - is not LOCK_INSERT_INTENSION type lock */ - - return(FALSE); - } - + if (( lock_is_on_supremum || (type_mode & LOCK_GAP)) + && !(type_mode & LOCK_INSERT_INTENTION)) { + /* Gap type locks without LOCK_INSERT_INTENTION flag + do not need to wait for anything. This is because different + users can have conflicting lock types on gaps. */ + + return(FALSE); + } + if ((type_mode & LOCK_REC_NOT_GAP) && lock_rec_get_gap(lock2)) { /* Lock on just the record does not need to wait for @@ -842,9 +842,12 @@ lock_has_to_wait( if (lock_get_type(lock1) == LOCK_REC) { ut_ad(lock_get_type(lock2) == LOCK_REC); - + /* If this lock request is for a supremum record + then the second bit on the lock bitmap is set */ + return(lock_rec_has_to_wait(lock1->trx, - lock1->type_mode, lock2,(ibool)lock_rec_get_nth_bit(lock1,1))); + lock1->type_mode, lock2, + lock_rec_get_nth_bit(lock1,1))); } return(TRUE); @@ -1433,7 +1436,8 @@ lock_rec_other_has_conflicting( lock = lock_rec_get_first(rec); while (lock) { - if (lock_rec_has_to_wait(trx, mode, lock, (ibool)page_rec_is_supremum(rec))) { + if (lock_rec_has_to_wait(trx, mode, lock, + page_rec_is_supremum(rec))) { return(lock); } -- cgit v1.2.1