When the transaction ends normally, the transaction commit operation is one of the main operations to achieve transaction atomicity. This process is very important. Below we focus on analyzing some important links in the transaction submission process.
The overall process of transaction submission
InnoDB and MySQL Server jointly implement the entire transaction submission process. For related processes, see Table 10-2 . In this table, from top to bottom, is a stack of the transaction submission process. The top is the top of the stack and the bottom of the stack is the bottom function. The upper layer function is called.
Table 10-2 Related function stack table for transaction submission
| Function name and function |
function procedure |
| trx_commit_in_memory Marks transaction completion in memory and then releases the transaction lock |
1. Call lock_trx_release_locks() to release the lock 2. Assert that the status of the transaction is completed in memory (the flag is set in the previous step) 3. Call trx_undo_insert_cleanup() to release the inserted UNDO log 4. Generate new LSN 5. Determine whether to call trx_flush_log_if_needed() to flush the log to physical storage (that is, whether to implement the write-ahead log mechanism)based on the value of the innodb_flush_log_at_trx_commit parameter. 6. If it is a rollback operation, set some values for the rollback operation, such as setting the transaction status to the macro TRX_STATE_FORCED_ROLLBACK 7. Reinitialize the structure value of the transaction object for reuse |
| trx_commit_low
|
1. Mini-Transaction transaction submission 2. Call trx_commit_in_memory() to complete operations such as transaction submission in memory. |
| trx_commit |
1. Call trx_commit_low() to complete transaction submission 2. It will also be called by trx_rollback_finish() for rollback operations. |
| trx_commit_for_mysql |
1. Perform different operations according to the status of the transaction. trx_commit is calledbecause the state of the transaction needs to change from TRX_STATE_ACTIVE or TRX_STATE_PREPARED to TRX_STATE_COMMITTED_IN_MEMORY |
| innobase_commit_low |
1. Call trx_commit_for_mysql() to complete transaction submission |
| innobase_commit |
1. Call innobase_commit_low() to complete the transaction submission (set the transaction commit flag and release transaction-related locks) 2. Call trx_commit_complete_for_mysql() to flush the log |
|
|
The above is the transaction submission related code of the InnoDB layer. From top to bottom are the main functions from the top of the stack to the bottom of the stack. |
| ha_commit_low |
The MySQL Server layer performs transaction management operations on the underlying storage through the handle interface, and calls InnoDB 's innobase_commit() function through the function pointer ht->commit(). |
| TC_LOG_DUMMY::commit |
The MySQL layer does not provide REDO log service, but provides a pseudo interface to simulate logical log submission operations. |
| ha_commit_trans |
Transaction commit by MySQL layer |
| trans_commit_stmt or trans_commit |
The transaction submission performed by the MySQL layer, the former is to submit a single statement transaction, and the latter is to submit a multi-statement transaction |
2. The relationship between transaction submission and log flushing
Normally, the database engine implements concurrency control technology through strict two-phase locking ( SS2PL , see Chapter 2), but in order to meet the consistency requirements of the data, the consistency C in the ACID characteristics of the transaction requires that the transaction must be Flushing the log first complies with the WAL pre-logging mechanism. However, InnoDB supports transaction submission but does not follow the WAL pre-logging mechanism, which may cause data inconsistency.
The following is the main process analysis of the innobase_commit() function. From this analysis, it can be seen that the transaction is first set with a commit flag, and then the lock is released. Then execute the trx_commit_complete_for_mysql() function to complete the log flushing operation. So we say that InnoDB does not comply with the WAL pre-logging mechanism.
/*****************************************************************//**
Commits a transaction in an InnoDB database or marks an SQL statement ended.
@return 0 or deadlock error if the transaction was aborted by another higher priority transaction. */
static
int
innobase_commit ( //Submit a transaction, complete the transaction submission identifier, and then flush the log (this method violates the WAL pre-write log mechanism )
handlerton* hton, /*!< in: InnoDB handlerton */ //InnoDB engine handle
THD* thd, /*!< in: MySQL thread handle of the user for whom the transaction should be committed */ //用户会话
bool commit_trx) /*!< in: true - commit transaction false - the current SQL statement ended */ // Whether to commit
{...
if (commit_trx // The value is TRUE to commit the transaction
|| (!thd_test_options(thd, OPTION_NOT_AUTOCOMMIT | OPTION_BEGIN))) {
...
innobase_commit_low (trx); //Call stack:-> trx_commit_for_mysql() -> trx_commit(trx) -> trx_commit_low() -> trx_commit_in_memory() -> lock_trx_release_locks(),execute the following important code in thelock_trx_release_locks () function :
//trx->state = TRX_STATE_COMMITTED_IN_MEMORY ; that is, setting the flag that the transaction submission has been completed in the memory, and the data of this transaction is immediately visible to other transactions
//...omit some code
//lock_release(trx); Release the lock after setting the flag that the transaction commit has been completed. The lock is released after the commit flag is set, in compliance with the SS2PL protocol
...
/* Now do a write + flush of logs. */
if (!read_on
trx_commit_complete_for_mysql (trx); //Important step: flush the log (for the process of flushing the log, please refer to Title 2 in the next section "Logging to disk")
}
} else { // Do not commit transaction
...
}
...
}