Transaction properties
Transaction has four properties: atomicity, consistency, isolation, durability. These four properties are usually called ACID properties.
-
Atomicity (atomicity): A transaction should be an integral part of the work unit, the transaction includes operations are either successful or not successful.
-
Consistency (consistency): the transaction is to be changed from a database to a consistent state to another consistent state. Consistency and atomicity are closely related.
-
Isolation (isolation): execution of a transaction can not be other transactions interference. I.e., operation and use of the data inside a transaction before the transaction is not committed to other concurrent transactions are isolated and can not influence each other concurrently executing transactions each.
-
Persistence (durability): a transaction once successfully submitted, change its data in the database should be permanent. The next operation or other faults should not have any effect on them.
Database problems in concurrent transactions
If you do not consider a transaction isolation, the following problems occur:
Dirty read
Dirty read transaction refers to a process where the data is read uncommitted transactions in another. When a transaction is a data modified several times, but this many times in this transaction changes are not committed, then a concurrent transactions to access the data, it will cause inconsistencies two transactions resulting data.
Non-repeatable read
Non-repeatable read means for certain pieces of data in the database, multiple transaction query returns a different range of data values (difference here refers to an inconsistent one or more content data, but the same number of data), which is due query interval, the transaction data will need to be revised and submitted to another transaction.
Repeating the reading and non-reading difference is dirty, is a dirty read transaction reads dirty data from another uncommitted transaction, while non-repeatable read is read from other transactions submitted. Note that in some cases, non-repeatable read is not a problem.
Magic Reading
Magic Reading is a phenomenon that occurs when a transaction non-independent execution. For example, transaction T1 to a data item in a table of all the lines made from "1" to "2" in the operation, but this time the value of the table row is inserted into a data item, the data item and the transaction T2 or "1" and committed to the database.
The operations of the transaction T1 users to see if we just modify the data, you will find there is a line not modify, in fact, this line is added from the transaction T2, like hallucinations, like, this is what has happened phantom reads.
Phantom reads and non-repeatable read are read another transaction has been submitted (this is different to dirty read), the difference is non-repeatable read may occur in the update, delete operations, and phantom read occurs in the insert operation .
Exclusive lock, shared lock
Exclusive lock (Exclusive), also known as X lock, write lock.
Shared lock (Shared), also known as S locks, read locks.
Have the following relationship between the reader locks:
-
A transaction data object added O S lock O read operations may be performed, but the operation can not be updated. During locking of the other transactions can lock O S added, but can not add X lock.
-
A transaction data object O plus the X lock, you can read and update O. Other transactions during the locking O can not add any locks.
That is, the relationship between the reader locks can be summarized as: read more single write
Transaction isolation level
There are several in a transaction isolation levels:
Uncommitted Read (Read Uncommitted)
Lost update to resolve the issue. If a transaction has begun to write, so it does not allow other matters simultaneously write, but allows other transactions to read the trip data. The isolation level can be "exclusive write locks" to achieve, namely the transaction need to be modified to some data must lock these data plus X, read data does not need to add S lock.
Read Committed (Read Committed)
Solve the problem of dirty read. Read data transaction allows other transactions continue to access the rows of data, but write uncommitted transactions will prevent other transactions from accessing the row. This can be, that the transaction needs to be modified must add X lock these data, plus the time required to read data S locks on some data "moment shared read locks" and "exclusive write lock" is achieved by, immediately after the data read completion S lock release, do not wait until the end of the transaction.
Repeatable read (Repeatable Read)
Prohibited non-repeatable reads and dirty reads, but sometimes phantom read data may occur. Read data transaction would be prohibited by a write transaction (but allowing the read transaction), the write transaction to prohibit any other transactions.
Mysql use the default isolation level. This "he wrote row lock" through "shared read locks" and realize that some matters need to be modified data must lock these data plus X, you need to add S locks when reading data, when the data is not immediately read complete S lock release, but wait until the end of the transaction release.
Serialization (the Serializable)
Solve the problem of the magic of reading. Provide strict transaction isolation. It requires serialization of the transaction, a transaction can be performed by one, rather than concurrently. Only through the "row-level locking" can not be achieved transaction serialization, it must ensure that the newly inserted data is not just execute a transaction query access to through other mechanisms.
MySQL isolation level implementation
The above is an explanation of some of the concepts of database theory, but in such a database MySQL, ORACLE, for performance reasons not entirely in accordance with the theory described above to achieve.
MVCC
Multi-version concurrency control (Multi-Version Concurrency Control, MVCC) is MySQL-based optimistic locking isolation level to achieve theoretical way, and for implementing the Read Committed Repeatable Read isolation level can achieve.
Implementation (isolation level is repeatable read)
Before it comes to how to achieve the introduction of two concepts:
-
System version number: an incremental number, each beginning a new transaction, the system will automatically increment the version number.
-
Services Version: system version number at the start of the transaction.
In MySQL, adds two fields in each table of data that follows:
-
Create a Version Number: When creating a row of data, system version number as the current version number assigned to create
-
Delete Version Number: When you delete a row of data, the current system version number as the deleted version number assigned
SELECT
When reading data select rule is: create a version number <= current transaction version number, delete the version number is empty or> version number of the current transaction.
Create a version number <= version number of the current transaction to ensure that no data out of the data after the start of the transaction created. This is why in the example in the beginning we will not find out the cause of data added later
Delete the version number is empty or> version number of the current transaction to ensure that at least the data is not deleted before the transaction is open, it should be checked out of the data.
INSERT
insert is the current system version number assigned to create a version number field.
UPDATE
Insert a new record, save the current transaction version is the version number of the row created, while preserving the current transaction to delete the original version to the line, in fact, here is the update by delete and insert to achieve.
DELETE
When you delete the current system version number assigned to delete the version number field, identifies the rows that will be deleted in a transaction, the data is not deleted even when the place is actually commit. According to the rules select the data will not be open to query the data.
Source link: https: //mp.weixin.qq.com/s/aChayHLI3TrJbfYT_oOuHg