introduction:
Write "transaction" before saying that, for the purposes of MySQL InnoDB engine support services, and MyISAM engine does not support transactions. The following will start with the basic concepts of affairs, some of the problems characteristic of the transaction as well as their properties brought in detail.
The concept Affairs
A transaction is a logical set of operations
Characteristics of the transaction
Atomicity (Atomicity)
A transaction is an indivisible unit of work, all operations in a transaction either succeed or fail.
Consistency (Consistency)
The integrity of the transactions that occur before and after the data must be consistent. Example: A: 200, B: 200, regardless of how the exchange between A, B, and 400 will eventually be guaranteed.
Isolation (Isolation)
When the multi-transaction concurrency access to the database, a transaction can not be other firms interference, data between multiple concurrent transactions to be isolated from each other. If you do not consider isolation, it will lead to many security problems, such as under: dirty reads, non-repeatable read, phantom read (dummy read), the following will introduce its expansion.
Persistent (Durability)
Once a transaction is committed, it changed data in the database is permanent, then even if the database fails nor should it have any impact
Do not consider some of the problems caused by isolation
Isolation is not considered brings several problems as follows: dirty reads, non-repeatable read, read phantom (dummy read)
Dirty read
A transaction reads B transaction update but not yet commit the data, if the B transaction is rolled back, then just read A transaction data will disappear.
Non-repeatable read
After the first query to a transaction record A, the case B after the record is updated transaction for the commit, the transaction A followed by a second query found that the recording data has changed, non-repeatable read occurs. ( Emphasis is read update data of other matters that have been submitted )
Magic Reading (dummy read)
A query to the transaction for the first time two rows, then transaction B is inserted (insert) after a commit record, then transaction A query found three rows, phantom read occurs. ( Emphasis is read other insert data transaction has been submitted )
(4) For non-repeatable read are the following thought:
①: a service opened a transaction (A), a first one of the data query (time 1) A transaction, after which another transaction (B) this record has been modified (time point 2) and you modify immediately submit (the time of filing of the transaction a has not yet submitted), this time in the business transaction a if there is need for further inquiry of the record occurs non-repeatable read. This program was written to be considered, but Repeatedable Read has prevented the problem for us. But for the Oracle database is not achieved the level of isolation, so have to pay attention when programming.
②: default ① point in time at 2 is acquired for that row exclusive lock (assuming that at the time point 1, the select statement added FOR UPDATE exclusive lock, then B transaction can only wait for the A end of the transaction, the release note lock not based on the end of the query statement ended (so not select ... for update queries on the outcome of the lock release), but ended in accordance with the end of the transaction), because B transaction is the default operation of the update statement recording plus exclusive lock, and a record can be added to an exclusive lock (shared lock can add multiple, exclusive lock can only add a; corresponding to the data record if the increase exclusively after the lock is not possible to add any lock, comprising shared lock.)
There is a point to mention: Isolation specifically how to achieve? (Locking and MVCC) this in the next chapter
(3) MySQL transaction four isolation levels:
Persistent (Durability Rev) :
SQL standard defines four types of isolation levels, including a number of specific rules, which defines changes to internal and external transaction is visible, which is not visible. Low levels of isolation generally support higher level of concurrent processing, and have lower overhead.
Read Uncommitted (Uncommitted read the contents of)
the isolation level, all transactions can see the results of other uncommitted transactions. This isolation level is rarely used in practice, because its performance is not much better than the other levels. Uncommitted read data, also called a dirty read (Dirty Read).
Read Committed (read submission)
This is the default isolation level for most database systems (MySQL, but not the default). It meets the simple definition of isolation: a transaction can only see the change has been submitted firms do. This isolation level also supports so-called non-repeatable read (Nonrepeatable Read), because other instances of the same transaction in the example of the process during which there may be a new commit, so select the same may return different results.
Repeatable Read (can be re-read)
This is the default MySQL transaction isolation level, it ensures that multiple instances of the same transaction at the time of concurrent reads the data, you will see the same data row. But in theory, it will lead to another thorny issue: Magic Reading (Phantom Read). Simply put, phantom read means that when a user reads a range of data row, another transaction and insert a new row within the range, when the user re-read the range of data rows, you will find a new " Phantom "line. InnoDB and Falcon storage engine through a multi-version concurrency control (MVCC, Multiversion Concurrency Control) mechanism to solve the problem.