JDBC transaction isolation level

This article summarizes JDBC transaction isolation levels.

The transaction isolation level defines what data is "visible" to the currently executing statement within a transaction. When accessing the database concurrently, the transaction isolation level defines the degree of crossover between multiple transactions accessing the same target data source.

The degree of crossover can be divided into the following categories.

degree of crossover

dirty reads

When a transaction can see the uncommitted data of another transaction, it is called dirty read. In other words, a transaction can modify the data and then it can be seen by other transactions before it is committed. If the transaction is rolled back instead of committed, the data seen by other transactions is incorrect and "dirty".

nonrepeatable reads (non-repeatable reads)

Suppose that transaction A reads a row of data, then transaction B changes the row of data, and then transaction A reads the row of data again. At this time, transaction A gets two different results.

phantom reads

Suppose transaction A reads a result set through a where condition, transaction B inserts a piece of data that meets the where condition of transaction A, and then when transaction A queries again through the same where condition, an extra piece of data is found.

Transaction isolation level

The JDBC specification adds the TRANSACTION_NONE isolation level to meet the four transaction isolation levels defined by SQL:2003. Isolation levels, from loosest to strictest, are ordered as follows:

TRANSACTION_NONE

This means that the current JDBC driver does not support transactions, and it also means that this driver does not conform to the JDBC specification.

TRANSACTION_READ_UNCOMMITTED

Allows a transaction to see data that has been modified by other transactions but not committed, which means that there may be dirty reads, non-repeatable reads, or phantom reads.

TRANSACTION_READ_COMMITTED

Changes made by a transaction will not be seen by other transactions until it is committed. This avoids dirty reads, but not non-repeatable reads and phantom reads.

TRANSACTION_REPEATABLE_READ

Dirty reads and non-repeatable reads are avoided, but phantom reads are still possible.

TRANSACTION_SERIALIZABLE

Dirty reads, non-repeatable reads, and phantom reads are avoided.

References

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324415211&siteId=291194637