When the fast lock is not applicable, call the slow lock logic ( lock_rec_lock_slow).See the RecLock::lock_size function.), the number of bits is directly set and returned. O When there is only one record lock on the page where the record is located, and the lock belongs to the current transaction, and the pre-allocated bitmap of this record lock can describe the current heap no (The number of pre-allocated bits = number of records on the page when the lock object is created + 64. The lock object will be directly created and added to rec_hash, and success will be returned. O There are no record locks on the page where the record is located. Fast lock can apply when the following conditions are met: For a scenario with few lock conflicts, this is a general locking mode ( lock_rec_lock_fast). (See previous descriptions about record lock LOCK_X.) For clearer descriptions, the impl is false by default in the process descriptions below. In it, if the first parameter impl is TRUE, and the existing lock on the current record is not in conflict with LOCK_X | LOCK_REC_NOT_GAP, no lock object needs to be created. The entry function of row locking is lock_rec_lock. By mounting lock objects to transaction objects, we can quickly check for any table locks held by the current transaction by mounting lock objects to the lock chain tables of the table object, we can check the global conflict situation on the table. We can see that the lock objects will be added to different sets or chain tables. The constructed lock objects are added to the trx_t::lock.table_locks set of the current transaction.The constructed lock objects will be added to the trx_t::x_locks chain table of the transaction and the dict_table_t::locks chain table of the table object.O If table_pool is used up, the memory will be used for allocation to create a lock object. The pre-allocated sizes of rec_pool and table_pool are both eight lock objects. Through the re-allocated memory approach, the resource-consuming memory allocation operations can be avoided when a global lock is held ( lock_sys->mutex). The other is trx_lock_t::table_pool, used for allocation of table lock objects. One is trx_lock_t::rec_pool which pre-allocates a group of lock objects for record lock distribution. O In the transaction object trx_t::lock, two pools are available. For non-AUTO-INC locks, the lock object will be allocated from a pool.O The lock object directly references the pre-created dict_table_t::autoinc_lock, and adds it to the trx_t::autoinc_locks set. We have mentioned earlier that when this value is not 0, insert operations to the auto increment columns will regress to the old style locking mode. O Increment dict_table_t::n_waiting_or_granted_auto_inc_locks. When an AUTO-INC lock is currently requested.If no conflicting lock exists, the lock object will be directly created ( lock_table_create) and added to the queue.O If no deadlock occurs, after you set relevant variables of the transaction object, the error code DB_LOCK_WAIT will be returned and the lock request enters the lock wait state. It can be deemed that the current session has obtained the lock and success is returned. When a deadlock exists: if the current session is selected as a victim, remove the lock request ( lock_table_remove_low), reset the wait_lock of the current transaction to empty, and return the error code DB_DEADLOCK if the current session is selected as a victor, the lock wait is removed. O Check whether a deadlock exists ( DeadlockChecker::check_and_resolve). O Create a wait lock object ( lock_table_create) If a conflicting lock object exists, the lock request needs to enter the waiting queue ( lock_table_enqueue_waiting).O Directly traverse the chain table dict_table_t::locks Check whether a table lock object that is in conflict with the locking mode currently applied for exists at present ( lock_table_other_has_incompatible).First, check whether a table lock of an equal or higher level has been applied in the trx_lock_t::table_locks of the current transaction.Every table object ( dict_table_t) keeps the table lock objects constructed on it, At the same time, every transaction object also keeps its own transaction lock. All the transaction lock objects in InnoDB are mounted on the global object lock_sys.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |