Database Transaction ISOLATION LEVEL

Turn from http://blog.163.com/[email protected]/blog/static/87199341201110295352451/, and make a few changes

The SQL standard defines a Class 4 isolation level, which includes specific rules to define which changes within and outside the transaction are visible and which are not. Low-level isolation levels generally support higher concurrency processing and have lower system overhead.

READ UNCOMMITTED (Read UNCOMMITTED content)

At this isolation level, all transactions can see the execution results of other uncommitted transactions. This isolation level is rarely used in real-world applications because it has no better performance than other levels. This isolation level results in dirty reads (drity read). READ UNCOMMITTED data, also known as dirty Read (Dirty read), such as to adjust MySQL to this level, hibernate just executes the flush data into the database, but at this time the transaction does not mention (commit).

Read Committed (read submit content)

This is the default isolation level for most database systems (but not MySQL default). It satisfies the simple definition of isolation: A transaction can only see changes that have been submitted to the firm. This isolation level results in so-called non-repeatable reads (nonrepeatable Read), which means that the data being read is inconsistent because there may be new commits in the process of other instances of the same transaction. Adding an Add statement between two identical SELECT statements can result in inconsistent results for the query, so it is possible for the same SELECT statement to return different results.

Repeatable Read (can be reread)

This is the default transaction isolation level for MySQL, which ensures that multiple instances of the same transaction are in concurrency. When you read the data, you see the same rows of data. In theory, however, this can lead to another tricky problem: Phantom reading (Phantom Read). To put it simply, Phantom reads when a user reads a range of data rows, another transaction inserts a new row within that range, and when the user reads the data row of that range, a new phantom row is found. the InnoDB and Falcon storage engines address this issue through a multi-version concurrency control (mvcc,multiversion Concurrency control) mechanism .

Serializable (Serializable)
This is the highest isolation level, which solves the Phantom reading problem by forcing transactions to sort, making it impossible to conflict with one another. In short, it is a shared lock on every data row read. At this level, a large number of timeouts and lock competitions can result.

These four isolation levels are implemented with different lock types, which can be problematic if the same data is being read. For example:

Dirty Reads (drity read): A transaction has updated one copy of the data, another transaction reads the same data at this time, for some reason, the previous rollback operation, the latter will read the data is not correct.

Non-repeatable read (non-repeatable Read): Data inconsistency in two queries for a transaction, which may be the original data that was inserted in the middle of a transaction update during the two query process.

Phantom Read (Phantom Read): In a transaction two times the number of data pens inconsistent, for example, one transaction queried several columns (row) of data, while another transaction at this time inserted a new column of data, the previous transaction in the next query, you will find that there are a few columns of data that it did not previously.

Database Transaction ISOLATION LEVEL