Introduction to Spring transaction isolation level and instance parsing, spring transaction

Introduction to Spring transaction isolation level and instance parsing, spring transaction

This article focuses on the introduction and examples of Spring transaction isolation level (solation level), as follows.

When two transactions operate on the records of the same database, what is the impact between them? This introduces the concept of transaction isolation level. The isolation of databases is closely related to concurrency control. The database isolation level is part of ACID, the transaction feature of the database. ACID, I .e., atomicity, consistency, isolation and durability ). Spring has four transaction isolation levels:READ_UNCOMMITTED,READ_COMMITTED,REPEATABLE_READAndSERIALIZABLE. Another is the default database isolation level.DEFAULTBy default, MySQL isREPEATABLE_READ.

Let's take a look.

READ_UNCOMMITTED

As the name suggests,READ_UNCOMMITTEDThis means that one transaction can read the uncommitted transaction records of another transaction. In other words, a transaction can read the data that is still uncommitted by other transactions. This is the weakest isolation level for Spring transactions. As shown in the figure below, transaction A starts and writes A record. At this time, transaction B reads data and reads this record. However, transaction A rolls back later. Therefore, the data read by transaction B is not valid (the database is in an invalid state ). This is called dirty read ). Except for dirty reading,READ_UNCOMMITTEDIt may also appearnon-repeatable read(Repeatable) andphantom read(Phantom read) problems.

READ_COMMITTED

READ_COMMITTEDIsolation level indicates that a transaction can only read committed records, but not uncommitted records. In other words, a transaction can only read the committed data, and it can't read the uncommitted data. Therefore, dirty read does not occur, but other problems may occur. See.

During the two read operations of transaction A, transaction B modifies the record and submits it. Therefore, the records read twice before and after transaction A are inconsistent. This problem is called non-repeatable read ). (If the two read records are inconsistent, you will find a problem when reading them again .)

Except for non-repeatable read,READ_COMMITTEDPhantom read may also occur.

REPEATABLE_READ

REPEATABLE_READ indicates that a transaction can read a certain record from the database multiple times, and the records read multiple times are consistent. This isolation level can avoid dirty read and non-repeatable read problems, but may cause phantom read problems. For example.

Transaction A reads A series of records from the database twice. During this period, transaction B inserts A record and submits it. When transaction A reads data for the second time, it reads the record that transaction B just inserted. During the transaction, transaction A reads A series of records inconsistent twice, which is called phantom read.

SERIALIZABLE

SERIALIZABLE is the strongest isolation level in Spring. When a transaction is executed, it will be locked at all levels. For example, the read and write operations will be locked, as if the transaction was executed in a serial way, rather than happening together. This prevents the appearance of dirty read, non-repeatable read, and phantom read. However, it may cause performance degradation.

DEFAULT

MySQL Default isREPEATABLE_READ.

Example

Next, let's look at an example. Start a transaction in the mysql database without committing the transaction. Then, another transaction reads the record.

At the beginning, the records in the database,

Next, enable transaction A in mysql and insert A record.

Set the transaction attribute of the service classREAD_UNCOMMITTED.

@Transactional(isolation=Isolation.READ_UNCOMMITTED)public class AccountService {private AccountDAO accountDAO;public AccountDAO getAccountDAO() {return accountDAO;}public void setAccountDAO(AccountDAO accountDAO) {this.accountDAO = accountDAO;}public void transfer(String from, String to, double money) {accountDAO.outMoney(from, money);accountDAO.inMoney(to, money);}public void readAllUser() {List<Account> accounts = accountDAO.getAllUser();for (Account account : accounts) {System.out.println(account);}}}

Run the following test class

package com.chris.service;import static org.junit.Assert.*;import org.junit.Test;import org.junit.runner.RunWith;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.test.context.ContextConfiguration;import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;@RunWith(SpringJUnit4ClassRunner.class)@ContextConfiguration("classpath:applicationContext.xml")public class ReadAllUserTest {@Autowired  private AccountService accountService;@Test  public void test() {accountService.readAllUser();}}

The result is as follows:

This transaction reads uncommitted data.

At this time, the transaction A started in mysql is rolled back.

mysql> rollback;

Run the program again and the result is

Account [name = Michael, money = 1000.0]
Account [name = Jane, money = 1000.0]
Account [name = Kate, money = 1000.0]

Summary

The above is all the content about Spring transaction isolation level and instance parsing. I hope it will be helpful to you. If you are interested, you can continue to refer to other related topics on this site. If you have any shortcomings, please leave a message. Thank you for your support!