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

The main content of this article is "Summary of the communication attributes of transactions in Spring". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn the summary of the communication attributes of transactions in Spring.

When we use Spring, we often use its declarative transaction. Simply configure some rules in the configuration file, and the transaction problem can be easily solved by using the AOP feature of Spring. This involves a transaction propagation attribute problem [Propagation], which is defined in the TransactionDefinition API. If you are interested, you can take a look at src. 7 options are available:

PROPAGATION_REQUIRED: supports the current transaction. If there is no current transaction, create a new transaction. This is the most common choice.

PROPAGATION_SUPPORTS: supports the current transaction, and if there is no transaction, it is executed in a non-transactional manner.

PROPAGATION_MANDATORY: supports the current transaction and throws an exception if there is no current transaction.

PROPAGATION_REQUIRES_NEW: create a new transaction and suspend the current transaction if it exists.

PROPAGATION_NOT_SUPPORTED: performs the operation in a non-transactional manner, suspending the current transaction if there is a current transaction.

PROPAGATION_NEVER: executes in a non-transactional manner, throwing an exception if a transaction currently exists.

PROPAGATION_NESTED: support the current transaction, add Savepoint points, commit or rollback synchronously with the current transaction.

Now combined with an example, apply the above various propagation properties to illustrate: first declare two bean:ServiceA and ServiceB, in which ServiceB is referenced

View plaincopy to clipboardprint?

ServiceA {

Void methodA () {

ServiceB.methodB ()

}

}

ServiceB {

Void methodB () {

/ /...

}

}

View plaincopy to clipboardprint?

ServiceA {

Void methodA () {

ServiceB.methodB ()

}

}

ServiceB {

Void methodB () {

/ /...

}

}

ServiceA {

Void methodA () {

ServiceB.methodB ()

}

}

ServiceB {

Void methodB () {

/ /...

}

} next, let's analyze them one by one:

PROPAGATION_REQUIRED

If you join a transaction that is not in another transaction, a new transaction will be created; for example, the transaction level of ServiceB.methodB is defined as PROPAGATION_REQUIRED, so since ServiceA.methodA has already started a transaction when ServiceA.methodA is executed, calling ServiceB.methodB,ServiceB.methodB will not start a new transaction when it sees that it is already running inside the transaction of ServiceA.methodA. And if ServiceA.methodA runs and finds that he is not in a transaction, he assigns a transaction to himself. In this way, if an exception occurs in ServiceA.methodA or anywhere within ServiceB.methodB, the transaction will be rolled back. Even if the transaction for ServiceB.methodB has been committed, ServiceA.methodA will be rolled back when fail rolls back, and ServiceB.methodB will roll back.

PROPAGATION_SUPPORTS

If you are currently in a transaction, that is, running in the form of a transaction, if you are no longer in a transaction, then running in the form of a non-transaction.

PROPAGATION_MANDATORY

Must be run in a transaction. That is, he can only be called by one parent transaction. Otherwise, he will throw an exception.

PROPAGATION_REQUIRES_NEW

For example, if we design that the transaction level of ServiceA.methodA is PROPAGATION_REQUIRED,ServiceB.methodB and the transaction level of ServiceA.methodA is PROPAGATION_REQUIRES_NEW, then when the execution reaches ServiceB.methodB, the transaction of ServiceA.methodA will be suspended and ServiceB.methodB will start a new transaction and wait for the transaction of ServiceB.methodB to complete before he continues to execute. The transaction difference between him and PROPAGATION_REQUIRED is the degree of rollback of the transaction. Because ServiceB.methodB is a new transaction, there are two different transactions. If the ServiceB.methodB has been committed, then the ServiceA.methodA fails to roll back, and ServiceB.methodB will not roll back. If ServiceB.methodB fails to roll back, if the exception he throws is caught by ServiceA.methodA, the ServiceA.methodA transaction may still commit.

PROPAGATION_NOT_SUPPORTED

Transactions are not currently supported. For example, if the transaction level of ServiceA.methodA is PROPAGATION_REQUIRED and the transaction level of ServiceB.methodB is PROPAGATION_NOT_SUPPORTED, then when ServiceB.methodB is executed, the transaction of ServiceA.methodA is suspended and he finishes running in a non-transactional state before continuing the transaction of ServiceA.methodA.

PROPAGATION_NEVER

Cannot run in a transaction. Assuming that the transaction level of ServiceA.methodA is PROPAGATION_REQUIRED and the transaction level of ServiceB.methodB is PROPAGATION_NEVER, then ServiceB.methodB will throw an exception.

PROPAGATION_NESTED

The key to understanding Nested is savepoint. The difference between him and PROPAGATION_REQUIRES_NEW is that PROPAGATION_REQUIRES_NEW has another transaction, which will be independent of his parent transaction, while Nested's transaction is dependent on his parent transaction, and his commit is to be committed with his parent transaction. In other words, if the parent transaction is finally rolled back, he will also roll back. And the advantage of Nested transactions is that he has a savepoint:

View plaincopy to clipboardprint?

ServiceA {

Void methodA () {

Try {

ServiceB.methodB ()

} catch (Exception e) {

/ / perform other business

ServiceC.methodC ()

}

}

}

View plaincopy to clipboardprint?

ServiceA {

Void methodA () {

Try {

ServiceB.methodB ()

} catch (Exception e) {

/ / perform other business

ServiceC.methodC ()

}

}

}

ServiceA {

Void methodA () {

Try {

ServiceB.methodB ()

} catch (Exception e) {

/ / perform other business

ServiceC.methodC ()

}

}

} that is, if ServiceB.methodB fails to roll back, ServiceA.methodA rolls back to the savepoint point, and ServiceA.methodA can choose another branch, such as ServiceC.methodC, to continue to try to complete its own transaction; but this transaction is not defined in the EJB standard.

At this point, I believe you have a deeper understanding of the "summary of the propagation attributes of transactions in Spring". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.