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

This article mainly introduces "what is the transaction isolation level and dissemination of Spring". In daily operation, I believe that many people have doubts about the meaning of transaction isolation level and communication of Spring. The editor consulted all kinds of data and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts of "what is the meaning of transaction isolation level and communication of Spring?" Next, please follow the editor to study!

This article begins with a question. If you know the answer, you can skip the @ (o ·answer) @.

Q: during the execution of a batch task, when multiple subtasks are called, if some subtasks have exceptions and only roll back those tasks that have exceptions, instead of the whole batch task, how to configure the transaction in Spring to achieve this function?

Isolation level

Isolation, as a key feature of transaction, requires that the object of each read-write transaction can be separated from the operating objects of other transactions, that is, the transaction is invisible to other transactions before it is committed, and locks are used at the database level.

There are four isolation levels for transactions from low to high:

READ UNCOMMITTED (uncommitted read): this is the lowest isolation level, which means that one transaction is allowed to read data that another transaction has not committed. READ UNCOMMITTED is a dangerous isolation level that is rarely used in actual development, mainly because it can cause dirty reading problems.

Time transaction 1 transaction 2 remarks 1 read inventory for 100-2 deduction of library layer 50 murmurs-remaining 503

Deducting 50m / m / s / s / s from 50m / m / s / s

Commit transaction inventory saved as 05 rollback transaction-transaction rollback is 0

Dirty reading is fatal for applications that require data consistency, and the isolation level of mainstream databases is not set to READ UNCOMMITTED. However, although dirty reading seems useless, its main advantage is its high concurrency ability, which is suitable for those scenarios that pursue high concurrency without requiring data consistency.

READ COMMITTED (read-write commit): it means that a transaction can only read data that has been committed by another transaction, not uncommitted data. READ COMMITTED brings unrepeatable problems:

Time transaction 1 transaction 2 remarks 1 read inventory is 1

2 deduction of inventory

Transaction not committed 3

Read inventory as 1

4 commit transaction

Inventory becomes 05

The deduction of inventory is 0 and cannot be deducted.

The difference between unrepeatable reading and dirty reading is that dirty reading gets uncommitted data, while non-repeatable reading does commit data, but violates the requirement of database transaction consistency.

Generally speaking, the problem of non-repeatable reading is acceptable because it reads the data that has been submitted and does not cause much problem in itself. Therefore, many databases, such as (ORACLE,SQL SERVER), set their default isolation level to READ COMMITTED, allowing non-repeatable readings.

REPEATABLE READ (repeatable readability): the goal of repeatable readability is to overcome the non-repeatable readings in READ COMMITED, which means that all queries within the same transaction are consistent with the beginning of the transaction. Taking the above table as an example, the following changes will occur under the REPEATABLE READ isolation level:

Time transaction 1 transaction 2 remarks 1 read inventory is 1

2 deduction of inventory

Transaction not committed 3

Read inventory is not allowed to read, wait for transaction 1 commit 4 commit transaction

Inventory becomes 05

Read inventory is 0 and cannot be deducted

Although REPEATABLE READ solves the problem of unrepeatable reading, it also brings the problem of phantom reading. phantom reading means that in a transaction, the first time you query a record and find that it does not exist, but when you try to update this record that does not exist, it is successful, and when you read the same record again, it miraculously appears.

Time transaction A transaction 2 remarks 1beginbegin

two

Read data with id 100th without data 3 insert data with id 100s

4 commit transaction

five

Reading data with an id of 100 has no data 6

Update data with id of 100 succeeded 7

Read data with an id of 100 successfully read 8

Commit transaction

When transaction B reads the record of id=99 for the first time in step 2, the read record is empty, indicating that there is no record of id=99. Transaction A then inserts an id=99 record and commits it in step 3. When transaction B reads id=99 's record again in step 5, the read record is still empty, but transaction B succeeds when it tries to update this non-existent record in step 6, and when transaction B reads id=99 's record again in step 8, the record appears.

SERIALIZABLE (serialization): the highest isolation level of a database, which requires all SQL to be executed sequentially, which can overcome the problems of all the above isolation and completely contain the consistency of the data.

Configure isolation levels in Spring

To configure the isolation level in a Spring project, you can only do the following

@ Transactional (isolation = Isolation.SERIALIZABLE) public int insertUser (User user) {return userDao.insertUser (user);}

In the above code, we use a serialized isolation level to contain data consistency, which will block other transactions for concurrency, so it can only be used in low concurrency scenarios where data consistency is needed.

Isolation level Dictionary:

DEFAULT (- 1), # # default database levels READ_UNCOMMITTED (1), READ_COMMITTED (2), REPEATABLE_READ (4), SERIALIZABLE (8); propagation behavior

In Spring, when one method calls another method, you can make the transaction work with a different strategy, such as creating a new transaction or suspending the current transaction, which is the propagation behavior of the transaction.

Define

There are seven kinds of propagation behaviors to the database in the transaction mechanism of Spring, which are defined by the enumeration class Propagation.

Public enum Propagation {/ * requires a transaction and propagates sexual behavior by default. * if there is a transaction, use the current transaction, otherwise create a new transaction running submethod * / REQUIRED (0), / * support the transaction, if there is a transaction, continue to use the current transaction, * if it does not exist, continue to run the submethod in a transactional manner * / SUPPORTS (1), / * you must use the transaction If there is no current transaction, throw an exception * if there is a current transaction, use the current transaction * / MANDATORY (2), / * create a new transaction allow method regardless of whether the current transaction exists or not * so that the new transaction can have new features such as locks and isolation levels. Independent of the current transaction * / REQUIRES_NEW (3), / * does not support transaction. If there is a transaction, the transaction will be suspended. The running method * / NOT_SUPPORTED (4), / * does not support transaction. If there is a transaction in the current method, an exception will be thrown. Otherwise, continue to run * / NEVER (5) with no transaction mechanism, / * if an exception occurs in the submethod when the current method invokes the submethod, * only the SQL executed by the roller method will be returned, but not the transaction of the current method * / NESTED (6). .}

Basically, only REQUIRED (0), REQUIRES_NEW (3) and NESTED (6) are used in daily development.

There is a difference between NESTED and REQUIRES_NEW. NESTED propagation behavior follows the isolation level and lock characteristics of the current transaction, while REQUIRES_NEW can have its own independent isolation level and lock characteristics.

The implementation of NESTED mainly depends on the database SavePoint (SAVEPOINT) technology. SAVEPOINT records a SavePoint that can be rolled back and forth to a SavePoint through ROLLBACK TO SAVEPOINT. SavePoint technology is enabled if the database supports SavePoint technology; if not, a new transaction is created to execute the code, which is equivalent to REQUIRES_NEW.

Transactional self-call invalidation

If you call your own method in a class, we call it self-calling. For example, an order business implementation class OrderServiceImpl has a methodA method that calls the methodB method of its own class, such as:

@ Transactionalpublic void methodA () {for (int I = 0; I < 10; iTunes +) {methodB ();} @ Transactional (isolation = Isolation.READ_COMMITTED,propagation = Propagation.REQUIRES_NEW) public int methodB () {.}

In the above method, no matter how methodB sets the isolation level and propagation behavior, it does not take effect. That is, self-invocation is invalid.

This is mainly because the underlying implementation principle of @ Transactional is based on AOP implementation, while the principle of AOP is dynamic proxy, which is called by the class itself in the process of self-invocation, not by the proxy object, so AOP will not be generated, so the phenomenon of self-call failure occurs.

There are two ways to overcome this problem:

Write two Service and use the methodA of one Service to call the methodB method of the other Service. This is the call of the proxy object, and there will be no problem.

In the same Service, methodA does not call methodB directly, but first retrieves the proxy object `OrderServiceImpl from the Spring IOC container, and then calls methodB. It's a bit of a mess, but it's still show you the code.

Public class OrderServiceImpl implements OrderService,ApplicationContextAware {private ApplicationContext applicationContext = null; @ Override public void setApplicationContext (ApplicationContext applicationContext) {this.applicationContext = applicationContext;} @ Transactional public void methodA () {OrderService orderService = applicationContext.getBean (OrderService.class); for (int I = 0; I < 10; iTunes +) {orderService.methodB () } @ Transactional (isolation = Isolation.READ_COMMITTED,propagation = Propagation.REQUIRES_NEW) public int methodB () {. }}

In the above code, we first implement the ApplicationContextAware interface, and then get the interface object of OrderService through applicationContext.getBean (). What you get at this time is a proxy object, so you can use the dynamic proxy of AOP normally.

Going back to the original question, do you have an answer after reading this article?

At this point, the study on "what is the meaning of transaction isolation level and communication of Spring" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.