Affairs
Definition: ABCD four business such as a transaction, either they have performed together completed, or none of them executed. (As long as one is not successful, then all can not succeed)
The four properties
ACID
Atomicity (Atomicity)
All the operation of the entire transaction, either all completed or not completed all.
Transaction error occurs during execution, it will be rolled back (Rollback) to the state before the transaction began.
Consistency (Consistency)
Services must maintain the state of the system is the same, regardless of concurrent transactions at any time how much.
Such as transfers, ABCDE five initial state of each person 100 yuan, the total is 500 yuan. At each transfer operation,
To hold the total amount of the overall system is still 500 yuan.
Isolation (Isolation)
Isolated state affairs operations, make them like themselves as the only operating within a given time.
If there are two transactions, at the same time, perform the same operations, transaction isolation requirements to ensure that each transaction only in the system
The transaction using the system.
Such properties are sometimes called serialization , in order to prevent confusion between the transaction operations must be serialized or serialization request, so that only one request at the same time request the same data
Persistent (Durability)
Because of an action often contain many sub-operations, and these operations may vary depending on the child as hardware damage or other factors cause problems to correctly implement ACID is not easy. ACID recommended that the database will need to update and modify all the data once the operation is completed, but in fact is not feasible.
There are two main ways to achieve ACID: The first is Write ahead logging, journaling is the way (modern databases are based on this way). The second is the Shadow paging.
With respect to the WAL (write ahead logging) technique, shadow paging technology is relatively simple, eliminating the overhead of writing log records, the speed of recovery is also fast (do not need to redo and undo). Shadow paging drawback is that when a transaction is committed to output a plurality of blocks, which makes a big overhead submitted, and in block units, difficult to apply to allow concurrent execution of multiple transactions in the case - this is its fatal flaw.
WAL central concept is that changes to data files (where tables and indexes reside) must be written only after those changes have been recorded in the log - that is, after flushed to permanent storage in logging. If we follow this process, then we do not need at the time of each transaction submitted to flush data pages to disk, because we know that in the event of a crash, we can use the log to restore the database: not yet attached to any data page the recording will start redo log record (called roll-forward recovery, also known as rEDO) and then those uncommitted transaction changes made will be removed (called backward scrolling recovery - UNDO) from the data page.
What is the WAL
"In computer science, write-ahead logging (WAL) is a family of techniques for providing atomicity and durability (two of the ACID properties) in database systems."——维基百科
In the computer field, WAL (Write-ahead logging, Write-Ahead Logging) database system provides persistence atoms and a series of techniques.
In a system using the WAL, all the modifications are first written to the log, and then is applied to the system state. Generally comprise two portions redo and undo information.
Why do I need to use WAL, then redo and undo information it contains? For example, if a system will change to the system state directly, then reboot the system after power down the machine needs to know the operation is successful, or only partial success or failure (in order to restore state). If the WAL, then after restarting the system can be determined by comparing logs and system status is to continue to complete the operation or undo.
redo log
redo log called a redo log whenever an operation, before the operation of writing the data changes redo log, so that when the power failure occurs like the case of the system can continue to operate after the restart.
undo log
undo log called the undo log, when some changes to the implementation of half can not be completed, it can be restored to the state in accordance with changes between undo log.
Repair data (durability of transactions) with MySQL where the redo log to restart the system when Crash class, the undo log to guarantee atomicity of transactions.
Isolate the problem
Dirty read
A transaction read data from another uncommitted transactions
Non-repeatable read
A transaction data read another transaction has been submitted.
Means: within the scope of a transaction, do the same query two times, but returned different results.
Cause: This is due to a transaction in the query, the system changes due to submit another transaction.
Examples: For example, a data read transaction T1, T2 transaction at this time to read and modify this data, in order to read T1
Value is then verify, and read the data again, you will get a different result.
Magic Reading
Magic happens when reading means are not independent execution of a transaction (such as disturbed other matters)
example:
BACKGROUND: A number of lines read transaction matching the search criteria, and transaction B is inserted or deleted to modify the transaction A search result set,
Then submit.
Scenario: A transaction data in a table was modified, then the same time, the transaction result set B also done just insert operation,
Add a new row , it has not submitted before the transaction A, found more than one row of data is not modified, as if produced hallucinations same.
Solution: Magic general approach is to increase the read range of solutions lock RangeS, narrow search range is read-only, thus avoiding the phantom reads.
In the database definition four isolation levels in
Can guarantee the highest level of isolation SERIALIZABLE_READ phantom read problem does not occur.
Repeatable Read (RR)
Isolation sector
MySQL InnoDB transaction isolation level there are four, default is "repeatable read" (REPEATABLE READ).
- Uncommitted read (READ UNCOMMITTED). Another transaction modifies the data, but not yet committed, and this transaction will read SELECT data (dirty read) has not been submitted.
- Read Committed (READ COMMITTED). This transaction reads to the latest data (after the other transaction commits). The problem is that, in the same transaction, the same SELECT twice before and will read a different result (not repeatable read).
- Repeatable Read (REPEATABLE READ). In the same transaction, the result of a SELECT is the state of affairs when the start point of time, therefore, the same SELECT operation read the result will be the same. However, there phantom read phenomenon (explained later).
- Serialization (SERIALIZABLE). Read implicitly acquire a shared lock, can ensure mutual exclusion between different transactions.
Mysql test isolation level of phantom read
Creating tables and checking engine
mysql> show create table t_bitfly\G;
CREATE TABLE `t_bitfly` (
`id` bigint(20) NOT NULL default '0',
`value` varchar(32) default NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=gbk
mysql> select @@global.tx_isolation, @@tx_isolation;
+-----------------------+-----------------+
| @@global.tx_isolation | @@tx_isolation |
+-----------------------+-----------------+
| REPEATABLE-READ | REPEATABLE-READ |
+-----------------------+-----------------+Mysql open two windows, two analog transactions A, B
Scenario: Analog B commit the transaction since a new transaction record operation execution A
t Session A Session B
|
| START TRANSACTION; |START TRANSACTION;
| |
| SELECT * FROM t_bitfly; |
| empty set |
| | INSERT INTO t_bitfly
| | VALUES (1, 'a');
|
| SELECT * FROM t_bitfly; |
| empty set |
| | COMMIT;
| |
| SELECT * FROM t_bitfly;
| empty set
|
| INSERT INTO t_bitfly VALUES (1, 'a');
| ERROR 1062 (23000):
| Duplicate entry '1' for key 1
(shit, 刚刚明明告诉我这没有这条记录的)
The results are as follows:
Experiments show that: RR isolation level does solve the problem of non-repeatable read because when the last read or not to read transaction B
The new record after submission.
But success does not insert himself (or update).
mysql for RR-level official to solve the phantom reads the explanation:
http://dev.mysql.com/doc/refman/5.0/en/innodb-record-level-locks.html
By default, InnoDB operates in REPEATABLE READ transaction isolation level and with the innodb_locks_unsafe_for_binlog system variable disabled. In this case, InnoDB uses next-key locks for searches and index scans, which prevents phantom rows (see Section 13.6.8.5, “Avoiding the Phantom Problem Using Next-Key Locking”).
Means: phantom reads can be solved by Next-Key Locking
The key point is that InnoDB is the default for a general inquiry will add next-key locks, or that need to apply themselves to lock it? If you look at this one, you may think that InnoDB query ordinary also added a lock, and if so, and serialization (SERIALIZABLE) difference where is it?
There is also some MySQL manual:
13.2.8.5. Avoiding the Phantom Problem Using Next-Key Locking (http://dev.mysql.com/doc/refman/5.0/en/innodb-next-key-locking.html)
To prevent phantoms,
InnoDBuses an algorithm called next-key locking that combines index-row locking with gap locking.You can use next-key locking to implement a uniqueness check in your application: If you read your data in share mode and do not see a duplicate for a row you are going to insert, then you can safely insert your row and know that the next-key lock set on the successor of your row during the read prevents anyone meanwhile inserting a duplicate for your row. Thus, the next-key locking enables you to “lock” the nonexistence of something in your table.
My understanding is to say, InnoDB provides next-key locks, but need to lock themselves to the application. An example is provided in the manual:
SELECT * FROM child WHERE id > 100 FOR UPDATE;
Thus, InnoDB will give greater than 100 id (id if the child list is a line 102), and the gap 100-102,102 + are locked together.
Show innodb status can be used to add to the table to see if the lock.
Transaction A Transaction B
start transaction; start transaction
select *from t_bitfly where id<=1 for update;
insert into t_bitfly values(2,'b');
Query OK, 1 row affected (0.36 sec)
// success! A lock here to prove if the transaction scope of the result set does not contain
Transaction B want to insert a range of key words (not in the range of 2 id <2), and
It can successfully executed
insert into t_bitfly values(0,'z');
Lock wait timeout exceeded; try restarting transaction
// time means that a transaction is not submitted by A, B because the scope of the transaction could never lock
Execution.
Additional comments:
· 1, the first example, after the transaction b commit a transaction not read (no phantom read), as insert failed because the primary key is not unique, even if this is certainly not visible success.
* 2, the second example, the query does not read fantasy, but there was extra data after the update, because the update time, it will update the version number of the next-key , if the update join condition, just check out the update id data 1, subsequent queries, or finding another one (no phantom read, update the version number of the update, so check out the data is legitimate)
example of the latter is an example of your lock, no problem. But it will consume much of the performance, in fact you do is SERIALIZABLE do.
Another point, you may have an understanding of next-key locks of some deviation, the so-called next-key locks are not really locked, just by version number, do the data isolation, and the version number (the current version, delete the two versions ) is the mysql innodb maintain their own hidden column . This isolation is to isolate the query, update, delete as well as insert, has its own version maintenance, to ensure the correctness of the query.
The savepoint mysql selectively achieve rollback of
ABCD a transaction
Connection conn = null;
try{
//1 获得连接
conn = ...;
//2 开启事务
conn.setAutoCommit(false);
A
B
C
D
//3 提交事务
conn.commit();
} catche(){
//4 回滚事务
conn.rollback();
}
AB (mandatory), CD (optional)
For example scenario: for example, the transfer operation is AB, CD texting bank operations
Connection conn = null;
Savepoint savepoint = null; //保存点，记录操作的当前位置，之后可以回滚到指定的位置。（可以回滚一部分）
try{
//1 获得连接
conn = ...;
//2 开启事务
conn.setAutoCommit(false);
A
B
savepoint = conn.setSavepoint();
C
D
//3 提交事务
conn.commit();
} catche(){
if(savepoint != null){ //CD异常
// 回滚到CD之前
conn.rollback(savepoint);
// 提交AB
conn.commit();
} else{ //AB异常
// 回滚AB
conn.rollback();
}
}