mirror of
https://github.com/MariaDB/server.git
synced 2025-01-31 11:01:52 +01:00
18eab4a832
The purpose of non-exclusive locks in a transaction is to guarantee that the records covered by those locks must remain in that way until the transaction is committed. (The purpose of gap locks is to ensure that a record that was nonexistent will remain that way.) Once a transaction has reached the XA PREPARE state, the only allowed further actions are XA ROLLBACK or XA COMMIT. Therefore, it can be argued that only the exclusive locks that the XA PREPARE transaction is holding are essential. Furthermore, InnoDB never preserved explicit locks across server restart. For XA PREPARE transations, we will only recover implicit exclusive locks for records that had been modified. Because of the fact that XA PREPARE followed by a server restart will cause some locks to be lost, we might as well always release all non-exclusive locks during the execution of an XA PREPARE statement. lock_release_on_prepare(): Release non-exclusive locks on XA PREPARE. trx_prepare(): Invoke lock_release_on_prepare() unless the isolation level is SERIALIZABLE or this is an internal distributed transaction with the binlog (not actual XA PREPARE statement). This has been discussed with Sergei Golubchik and Andrei Elkin. Reviewed by: Sergei Golubchik |
||
|---|---|---|
| .. | ||
| archive | ||
| blackhole | ||
| cassandra | ||
| columnstore | ||
| connect | ||
| csv | ||
| example | ||
| federated | ||
| federatedx | ||
| heap | ||
| innobase | ||
| maria | ||
| mroonga | ||
| myisam | ||
| myisammrg | ||
| oqgraph | ||
| perfschema | ||
| rocksdb | ||
| sequence | ||
| sphinx | ||
| spider | ||
| test_sql_discovery | ||
| tokudb | ||