record using primary key from 2 different connections, 1 connection successes deleting, another connection waits that the lock is released. - The waiting connection gets a DEAD LOCK error when the connection which succeed deleting inserts a row that is same primary key. Detail of the issue
waiting when this connection tries getting the record lock of pk=1. Connection 2 gets a DEAD LOCK error because connection 1 should wait for a GAP lock caused by connection 2 when connection 1 tests an INSERT INTENTION GAP lock. Detail of the issue start transaction delete from t1 where pk = 1; delete from t1 where pk = 1; LOCK waiting insert into t1 (pk) values (1); DEAD LOCK
locks (except INSERT INTENTION GAP locks) or some record locks (except NOT GAP record locks) on the next key of a inserting record, this inserting waits for releasing locks. After passing this check, the INSERT INTENTION GAP lock is released immediately. - Implicit record lock It becomes a NOT GAP record lock when this record is checked by another locks. When inserting, check the lock conflict using INSERT INTENTION GAP lock, and after inserting, check the lock conflict using implicit record lock. Locks (REPEATABLE READ) of INSERT (excerpt)
inserting, checking INSERT INTENTION GAP lock can be omitted if it falls under any of the following cases. - The exclusive record lock has already been acquired by same connection for the inserting record. (After updating, deleting, etc) Thinking about omitting INSERT INTENTION GAP lock
and perform deleting and inserting on READ COMMITTED. - Performs additional exclusive control so that processing for the same record is not performed at the same time. - Examines whether retry processing is possible at getting DEAD LOCK error and performs retry processing. Current solutions