This article tells about the four characteristics of transactions in the database (ACID), and will explain the isolation level of transactions in detail.
If a database claims to support transactional operations, then the database must have the following four characteristics:
(1) Atomicity
Atomicity means that all operations contained in a transaction are either successful or all failed and rolled back. This is the same concept as the function of the transaction introduced in the previous two blogs. Therefore, if the operation of the transaction is successful, it must be fully applied to the database. Failure must not have any effect on the database.
⑵ Consistency
Consistency means that a transaction must bring the database from one consistent state to another consistent state, that is, a transaction must be in a consistent state before and after execution.
Take the transfer as an example, assuming that the sum of the money of user A and user B is 5,000, then no matter how the money is transferred between A and B, after several transfers, the sum of the money of the two users should be returned after the transaction is over. is 5000, which is the consistency of the transaction.
(3) Isolation
Isolation means that when multiple users access the database concurrently, such as when operating the same table, the transaction opened by the database for each user cannot be interfered by the operations of other transactions, and multiple concurrent transactions must be isolated from each other.
That is to achieve such an effect: for any two concurrent transactions T1 and T2, in the view of transaction T1, T2 either ends before T1 starts, or starts after T1 ends, so that each transaction does not feel until there are other transactions executing concurrently.
Isolation on Transactions Databases offer a variety of isolation levels, which will be described later.
⑷ Durability
Durability means that once a transaction is committed, the changes to the data in the database are permanent, and the operation of committing the transaction will not be lost even if the database system encounters a failure.
For example, when we use JDBC to operate the database, after submitting the transaction method, the user is prompted that the transaction operation is completed. When our program execution is completed until we see the prompt, we can determine the transaction and submit it correctly. Even if there is a problem with the database at this time, we must We need to complete our transaction completely, otherwise we will see a major error indicating that the transaction is completed, but the database failed to execute the transaction because of the failure.
The four characteristics of transactions (ACID for short) have been introduced above. Now we will focus on the isolation of transactions. When multiple threads open transactions to operate data in the database, the database system must be able to perform isolation operations to ensure that each thread obtains The accuracy of the data, before introducing the various isolation levels provided by the database, let's take a look at several problems that will occur if the isolation of the transaction is not considered:
1. Dirty read
Dirty read refers to reading data from another uncommitted transaction during one transaction.
When a transaction is modifying a certain data multiple times, and these multiple modifications have not been committed in this transaction, then a concurrent transaction accesses the data, which will cause the data obtained by the two transactions to be inconsistent. For example: user A transfers 100 yuan to user B, the corresponding SQL command is as follows
update account set money = money + 100 where name = 'B'; (A informs B at this time) update account set money=money - 100 where name=’A’;
When only the first SQL is executed, A notifies B to check the account, and B finds that the money has indeed arrived (that is, a dirty read occurs at this time), and then no matter whether the second SQL is executed or not, as long as the transaction is not committed, all The operations will be rolled back, so when B checks the account again later, he will find that the money has not actually been transferred.
2. Non-repeatable read
Non-repeatable read means that for a certain data in the database, multiple queries within the scope of a transaction return different data values, because it is modified and committed by another transaction during the query interval.
For example, transaction T1 is reading a certain data, and transaction T2 immediately modifies the data and submits the transaction to the database. Transaction T1 reads the data again and obtains a different result, sending a non-repeatable read.
The difference between a non-repeatable read and a dirty read is that a dirty read is a transaction that reads uncommitted dirty data of another transaction, while a non-repeatable read is a read of the data submitted by the previous transaction.
In some cases, non-repeatable reading is not a problem. For example, when we query a certain data multiple times, of course, the results obtained by the last query are the main ones. But in other cases, problems may occur. For example, for the same data, A and B may be queried in sequence, and A and B may fight...
3. Virtual reading (phantom reading)
A phantom read is a phenomenon that occurs when a transaction is not executed independently. For example, transaction T1 modifies a data item of all rows in a table from "1" to "2". At this time, transaction T2 inserts a row of data item into this table, and the value of this data item Still "1" and committed to the database. If the user who operates transaction T1 checks the data just modified, he will find that there is one row that has not been modified. In fact, this row is added from transaction T2, as if hallucinations occur. This is a hallucination reading.
Both phantom reads and non-repeatable reads read another committed transaction (this is different from dirty reads), the difference is that non-repeatable reads query the same data item, while phantom reads target a batch of The data as a whole (such as the number of data).
Now let's take a look at the four isolation levels that MySQL database provides us:
① Serializable (serialization): It can avoid the occurrence of dirty reads, non-repeatable reads, and phantom reads.
② Repeatable read: It can avoid the occurrence of dirty reads and non-repeatable reads.
③ Read committed (read committed): to avoid the occurrence of dirty reads.
④ Read uncommitted (read uncommitted): the lowest level, no guarantee under any circumstances.
The highest of the above four isolation levels is the Serializable level, and the lowest is the Read uncommitted level. Of course, the higher the level, the lower the execution efficiency. A level like Serializable uses a lock table (similar to the lock in Java multi-threading) so that other threads can only wait outside the lock, so the isolation level usually selected should be based on the actual situation. The default isolation level in MySQL databases is Repeatable read.
In the MySQL database, the above four isolation levels are supported, and the default is Repeatable read; in the Oracle database, only the Serializable (serialization) level and the Read committed (read committed) level are supported. , the default is Read committed level.
View the isolation level of the current transaction in the MySQL database:
select @@tx_isolation;
To set the isolation level of a transaction in a MySQL database:
set [ glogal | session ] transaction isolation level isolation level name; set tx_isolation = 'Isolation level name;'
Example 1: View the isolation level of the current transaction:
Example 2: Set the isolation level of the transaction to the Read uncommitted level:
or:
Remember: setting the isolation level of the database must be before starting the transaction!
If JDBC is used to set the isolation level for database transactions, it should also be called before the setAutoCommit(false) method of the Connection object. Call the setTransactionIsolation(level) of the Connection object to set the isolation level of the current link. As for the parameter level, you can use the fields of the Connection object:
Part of the code to set the isolation level in JDBC:
Postscript: The setting of the isolation level is only valid for the current link . For using the MySQL command window, a window is equivalent to a link, and the isolation level set by the current window is only valid for the transaction in the current window; for JDBC operating the database, a Connection object is equivalent to a link, and for the Connection object The set isolation level is only valid for this Connection object and has nothing to do with other linked Connection objects.
Reference blog:
http://www.zhihu.com/question/23989904
http://dev.mysql.com/doc/refman/5.6/en/set-transaction.html
http://www.cnblogs.com/xdp-gacl/p/3984001.html