Shulou(Shulou.com)06/01 Report--

Isolation level of the transaction

The isolation level of a transaction is derived from the I (Isolation) of the transaction ACID, that is, when multiple transactions operate the same entity at the same time, the read and write operations of one transaction affect the visibility of the other transactions and themselves. It can be divided into the following levels:

Read unsubmitted

Before a transaction commits, the modified data is visible to other transactions, and this level of isolation is the lowest. There is almost no isolation to other transactions except to ensure the atomicity of the executing transaction itself, so if the source transaction is rolled back, other transactions will be dirty read.

Read submitted

A transaction writes to data, and other transactions are not visible until they are committed. This is a relatively reliable plan. It is also the default isolation level for many databases. There are also two major problems with read commit. The first is that if two transactions are opened at the same time, the data read by one transaction for the first time will be inconsistent with the data read after the other transaction is modified and committed, that is, it can not be read repeatedly; the second problem is that it is easy to cause deadlocks.

Repeatable read

Once a transaction starts a read operation on data, other transactions can no longer write, which is equivalent to a read lock. Repeatable reading increases the security of data, but for new operations, there is still a problem of phantom reading.

Serialization

Serialization is not only the most secure isolation class, but also the least used isolation level, transaction serialization execution, throughput is seriously limited. The propagation level of the transaction

Unlike the isolation level of a transaction, the propagation feature means that after a transaction is opened, if calls to other transactions are involved in the transaction, whether the main transaction is used, or the new transaction is opened, or the transaction is not accepted.

REQUIRED supports the current transaction if there is a transaction. If not, start a new transaction. SUPPORTS supports the current transaction if there is a transaction. If not, follow the execution of the non-transaction. MANDATORY supports the current transaction if a transaction already exists. If not, an exception is thrown. REQUIRES_NEW always starts a new transaction. If a transaction already exists, the existing transaction is suspended. NOT_SUPPORTED always executes on a non-transactional basis and suspends any existing transactions. NEVER is always executed in a non-transactional manner. If there is an active transaction, an exception is thrown NESTED. If an active transaction exists, it runs in a nested transaction. If there is no active transaction, press the REQUIRED property to execute.

NESTED propagates the level if the outer transaction cannot roll back the in-memory committed transaction.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.