/* An explicit record lock affects both the record and the gap before it. An implicit x-lock does not affect the gap, it only locks the index record from read or update. If a transaction has modified or inserted an index record, then it owns an implicit x-lock on the record. On a secondary index record, a transaction has an implicit x-lock also if it has modified the clustered index record, the max trx id of the page where the secondary index record resides is >= trx id of the transaction (or database recovery is running), and there are no explicit non-gap lock requests on the secondary index record. This complicated definition for a secondary index comes from the implementation: we want to be able to determine if a secondary index record has an implicit x-lock, just by looking at the present clustered index record, not at the historical versions of the record. The complicated definition can be explained to the user so that there is nondeterminism in the access path when a query is answered: we may, or may not, access the clustered index record and thus may, or may not, bump into an x-lock set there. Different transaction can have conflicting locks set on the gap at the same time. The locks on the gap are purely inhibitive: an insert cannot be made, or a select cursor may have to wait if a different transaction has a conflicting lock on the gap. An x-lock on the gap does not give the right to insert into the gap. An explicit lock can be placed on a user record or the supremum record of a page. The locks on the supremum record are always thought to be of the gap type, though the gap bit is not set. When we perform an update of a record where the size of the record changes, we may temporarily store its explicit locks on the infimum record of the page, though the infimum otherwise never carries locks. A waiting record lock can also be of the gap type. A waiting lock request can be granted when there is no conflicting mode lock request by another transaction ahead of it in the explicit lock queue. In version 4.0.5 we added yet another explicit lock type: LOCK_REC_NOT_GAP. It only locks the record it is placed on, not the gap before the record. This lock type is necessary to emulate an Oracle-like READ COMMITTED isolation level. ------------------------------------------------------------------------- RULE 1: If there is an implicit x-lock on a record, and there are non-gap ------- lock requests waiting in the queue, then the transaction holding the implicit x-lock also has an explicit non-gap record x-lock. Therefore, as locks are released, we can grant locks to waiting lock requests purely by looking at the explicit lock requests in the queue. RULE 3: Different transactions cannot have conflicting granted non-gap locks ------- on a record at the same time. However, they can have conflicting granted gap locks. RULE 4: If a there is a waiting lock request in a queue, no lock request, ------- gap or not, can be inserted ahead of it in the queue. In record deletes and page splits new gap type locks can be created by the database manager for a transaction, and without rule 4, the waits-for graph of transactions might become cyclic without the database noticing it, as the deadlock check is only performed when a transaction itself requests a lock! ------------------------------------------------------------------------- An insert is allowed to a gap if there are no explicit lock requests by other transactions on the next record. It does not matter if these lock requests are granted or waiting, gap bit set or not, with the exception that a gap type request set by another transaction to wait for its turn to do an insert is ignored. On the other hand, an implicit x-lock by another transaction does not prevent an insert, which allows for more concurrency when using an Oracle-style sequence number generator for the primary key with many transactions doing inserts concurrently. A modify of a record is allowed if the transaction has an x-lock on the record, or if other transactions do not have any non-gap lock requests on the record. A read of a single user record with a cursor is allowed if the transaction has a non-gap explicit, or an implicit lock on the record, or if the other transactions have no x-lock requests on the record. At a page supremum a read is always allowed. In summary, an implicit lock is seen as a granted x-lock only on the record, not on the gap. An explicit lock with no gap bit set is a lock both on the record and the gap. If the gap bit is set, the lock is only on the gap. Different transaction cannot own conflicting locks on the record at the same time, but they may own conflicting locks on the gap. Granted locks on a record give an access right to the record, but gap type locks just inhibit operations. NOTE: Finding out if some transaction has an implicit x-lock on a secondary index record can be cumbersome. We may have to look at previous versions of the corresponding clustered index record to find out if a delete marked secondary index record was delete marked by an active transaction, not by a committed one. FACT A: If a transaction has inserted a row, it can delete it any time without need to wait for locks. PROOF: The transaction has an implicit x-lock on every index record inserted for the row, and can thus modify each record without the need to wait. Q.E.D. FACT B: If a transaction has read some result set with a cursor, it can read it again, and retrieves the same result set, if it has not modified the result set in the meantime. Hence, there is no phantom problem. If the biggest record, in the alphabetical order, touched by the cursor is removed, a lock wait may occur, otherwise not. PROOF: When a read cursor proceeds, it sets an s-lock on each user record it passes, and a gap type s-lock on each page supremum. The cursor must wait until it has these locks granted. Then no other transaction can have a granted x-lock on any of the user records, and therefore cannot modify the user records. Neither can any other transaction insert into the gaps which were passed over by the cursor. Page splits and merges, and removal of obsolete versions of records do not affect this, because when a user record or a page supremum is removed, the next record inherits its locks as gap type locks, and therefore blocks inserts to the same gap. Also, if a page supremum is inserted, it inherits its locks from the successor record. When the cursor is positioned again at the start of the result set, the records it will touch on its course are either records it touched during the last pass or new inserted page supremums. It can immediately access all these records, and when it arrives at the biggest record, it notices that the result set is complete. If the biggest record was removed, lock wait can occur because the next record only inherits a gap type lock, and a wait may be needed. Q.E.D. */ /* If an index record should be changed or a new inserted, we must check the lock on the record or the next. When a read cursor starts reading, we will set a record level s-lock on each record it passes, except on the initial record on which the cursor is positioned before we start to fetch records. Our index tree search has the convention that the B-tree cursor is positioned BEFORE the first possibly matching record in the search. Optimizations are possible here: if the record is searched on an equality condition to a unique key, we could actually set a special lock on the record, a lock which would not prevent any insert before this record. In the next key locking an x-lock set on a record also prevents inserts just before that record. There are special infimum and supremum records on each page. A supremum record can be locked by a read cursor. This records cannot be updated but the lock prevents insert of a user record to the end of the page. Next key locks will prevent the phantom problem where new rows could appear to SELECT result sets after the select operation has been performed. Prevention of phantoms ensures the serilizability of transactions. What should we check if an insert of a new record is wanted? Only the lock on the next record on the same page, because also the supremum record can carry a lock. An s-lock prevents insertion, but what about an x-lock? If it was set by a searched update, then there is implicitly an s-lock, too, and the insert should be prevented. What if our transaction owns an x-lock to the next record, but there is a waiting s-lock request on the next record? If this s-lock was placed by a read cursor moving in the ascending order in the index, we cannot do the insert immediately, because when we finally commit our transaction, the read cursor should see also the new inserted record. So we should move the read cursor backward from the the next record for it to pass over the new inserted record. This move backward may be too cumbersome to implement. If we in this situation just enqueue a second x-lock request for our transaction on the next record, then the deadlock mechanism notices a deadlock between our transaction and the s-lock request transaction. This seems to be an ok solution. We could have the convention that granted explicit record locks, lock the corresponding records from changing, and also lock the gaps before them from inserting. A waiting explicit lock request locks the gap before from inserting. Implicit record x-locks, which we derive from the transaction id in the clustered index record, only lock the record itself from modification, not the gap before it from inserting. How should we store update locks? If the search is done by a unique key, we could just modify the record trx id. Otherwise, we could put a record x-lock on the record. If the update changes ordering fields of the clustered index record, the inserted new record needs no record lock in lock table, the trx id is enough. The same holds for a secondary index record. Searched delete is similar to update. PROBLEM: What about waiting lock requests? If a transaction is waiting to make an update to a record which another modified, how does the other transaction know to send the end-lock-wait signal to the waiting transaction? If we have the convention that a transaction may wait for just one lock at a time, how do we preserve it if lock wait ends? PROBLEM: Checking the trx id label of a secondary index record. In the case of a modification, not an insert, is this necessary? A secondary index record is modified only by setting or resetting its deleted flag. A secondary index record contains fields to uniquely determine the corresponding clustered index record. A secondary index record is therefore only modified if we also modify the clustered index record, and the trx id checking is done on the clustered index record, before we come to modify the secondary index record. So, in the case of delete marking or unmarking a secondary index record, we do not have to care about trx ids, only the locks in the lock table must be checked. In the case of a select from a secondary index, the trx id is relevant, and in this case we may have to search the clustered index record. PROBLEM: How to update record locks when page is split or merged, or -------------------------------------------------------------------- a record is deleted or updated? If the size of fields in a record changes, we perform the update by a delete followed by an insert. How can we retain the locks set or waiting on the record? Because a record lock is indexed in the bitmap by the heap number of the record, when we remove the record from the record list, it is possible still to keep the lock bits. If the page is reorganized, we could make a table of old and new heap numbers, and permute the bitmaps in the locks accordingly. We can add to the table a row telling where the updated record ended. If the update does not require a reorganization of the page, we can simply move the lock bits for the updated record to the position determined by its new heap number (we may have to allocate a new lock, if we run out of the bitmap in the old one). A more complicated case is the one where the reinsertion of the updated record is done pessimistically, because the structure of the tree may change. PROBLEM: If a supremum record is removed in a page merge, or a record --------------------------------------------------------------------- removed in a purge, what to do to the waiting lock requests? In a split to the right, we just move the lock requests to the new supremum. If a record is removed, we could move the waiting lock request to its inheritor, the next record in the index. But, the next record may already have lock requests on its own queue. A new deadlock check should be made then. Maybe it is easier just to release the waiting transactions. They can then enqueue new lock requests on appropriate records. PROBLEM: When a record is inserted, what locks should it inherit from the ------------------------------------------------------------------------- upper neighbor? An insert of a new supremum record in a page split is always possible, but an insert of a new user record requires that the upper neighbor does not have any lock requests by other transactions, granted or waiting, in its lock queue. Solution: We can copy the locks as gap type locks, so that also the waiting locks are transformed to granted gap type locks on the inserted record. */ /* LOCK COMPATIBILITY MATRIX * IS IX S X AI * IS + + + - + * IX + + - - + * S + - + - - * X - - - - - * AI + + - - - * * Note that for rows, InnoDB only acquires S or X locks. * For tables, InnoDB normally acquires IS or IX locks. * S or X table locks are only acquired for LOCK TABLES. * Auto-increment (AI) locks are needed because of * statement-level MySQL binlog. * See also lock_mode_compatible(). */
/* Basic lock modes */ enum lock_mode { LOCK_IS = 0, /* intention shared */ LOCK_IX, /* intention exclusive */ LOCK_S, /* shared */ LOCK_X, /* exclusive */ LOCK_AUTO_INC, /* locks the auto-inc counter of a table in an exclusive mode */ LOCK_NONE, /* this is used elsewhere to note consistent read */ LOCK_NUM = LOCK_NONE/* number of lock modes */ }; /* A table lock */ typedef struct lock_table_struct lock_table_t; struct lock_table_struct { dict_table_t* table; /* database table in dictionary cache */ UT_LIST_NODE_T(lock_t) locks; /* list of locks on the same table */ }; /* Record lock for a page */ typedef struct lock_rec_struct lock_rec_t; struct lock_rec_struct { ulint space; /* space id */ ulint page_no; /* page number */ ulint n_bits; /* number of bits in the lock bitmap; NOTE: the lock bitmap is placed immediately after the lock struct */ }; /* Lock struct */ struct lock_struct { trx_t* trx; /* transaction owning the lock */ UT_LIST_NODE_T(lock_t) trx_locks; /* list of the locks of the transaction */ ulint type_mode; /* lock type, mode, LOCK_GAP or LOCK_REC_NOT_GAP, LOCK_INSERT_INTENTION, wait flag, ORed */ hash_node_t hash; /* hash chain node for a record lock */ dict_index_t* index; /* index for a record lock */ union { lock_table_t tab_lock;/* table lock */ lock_rec_t rec_lock;/* record lock */ } un_member; }; /* The lock system struct */ struct lock_sys_struct{ hash_table_t* rec_hash; /* hash table of the record locks */ }; //元组锁的模式 #define LOCK_ORDINARY 0 /*!< this flag denotes an ordinary next-key lock in contrast to LOCK_GAP or LOCK_REC_NOT_GAP */ #define LOCK_GAP 512 /*!< when this bit is set, it means that the lock holds only on the gap before the record; for instance, an x-lock on the gap does not give permission to modify the record on which the bit is set; locks of this type are created when records are removed from the index chain of records */ #define LOCK_REC_NOT_GAP 1024 /*!< this bit means that the lock is only on the index record and does NOT block inserts to the gap before the index record; this is used in the case when we retrieve a record with a unique key, and is also used in locking plain SELECTs (not part of UPDATE or DELETE) when the user has set the READ COMMITTED isolation level */ #define LOCK_INSERT_INTENTION 2048 /*!< this bit is set when we place a waiting gap type record lock request in order to let an insert of an index record to wait until there are no conflicting locks by other transactions on the gap; note that this flag remains set when the waiting lock is granted, or if the lock is inherited to a neighboring record */
对于表锁，是在对表加锁时申请的，记录在 事务 和 表在内存的缓存 这两个结构中
对于元组锁（行锁），在加锁时申请，记录在 事务 和 lock_sys->rec_hash 全局锁hash中，并不是每一个行锁一个表结构，而是按页面申请一个锁，根据行在页面中的序号，对相应的bit置位来表示加锁的，大大节省了元组锁的数量，根据锁的类型数量，同一个页面最多有这么多个锁
