Spring transaction transmission

Spring transaction transmission

This article mainly discusses the following obtaining points 【]:

I. Introduction to the transmission of Spring transactions

Ii. Third-party call of services containing transactions throwing exceptions

 

I. Introduction to the transmission of Spring transactions

Transaction Propagation Behavior. The transaction Propagation Behavior refers to the execution behavior of a transaction method if a transaction context already exists before the current transaction starts. The definition of TransactionDefinition includes the following constants that indicate the Propagation Behavior:

TransactionDefinition. PROPAGATION_REQUIRED: this transaction is added if a transaction exists. If no transaction exists, a new transaction is created.

TransactionDefinition. PROPAGATION_REQUIRES_NEW: Creates a new transaction. If a transaction exists, the current transaction is suspended.

TransactionDefinition. PROPAGATION_SUPPORTS: if a transaction exists, it is added to the transaction. If no transaction exists, it continues to run as a non-transaction.

TransactionDefinition. PROPAGATION_NOT_SUPPORTED: runs in non-transaction mode. If a transaction exists, the current transaction is suspended.

TransactionDefinition. PROPAGATION_NEVER: runs in non-transaction mode. If a transaction exists, an exception is thrown.

TransactionDefinition. PROPAGATION_MANDATORY: this transaction is added if a transaction exists. If no transaction exists, an exception is thrown.

TransactionDefinition. PROPAGATION_NESTED: if a transaction exists, create a transaction to run as a nested transaction of the current transaction. If no transaction exists, the value is equivalent to TransactionDefinition. PROPAGATION_REQUIRED.

It should be pointed out that the previous six transaction propagation behaviors are introduced by Spring from EJB and they share the same concept. PROPAGATION_NESTED is unique to Spring. Transactions started with PROPAGATION_NESTED are embedded in external transactions (if an external transaction exists). At this time, the embedded transaction is not an independent transaction and depends on the existence of external transactions, internal transactions can only be committed through external transactions. nested subtransactions cannot be committed independently. If you are familiar with the concept of SavePoint in JDBC, nested transactions are easy to understand. In fact, nested sub-transactions are an application that saves points, A transaction can contain multiple storage points and each nested sub-transaction. In addition, the rollback of external transactions will also lead to the rollback of nested sub-transactions.

 

Ii. Third-party call of services containing transactions throwing exceptions

Assume that the terms are as follows: Conumer of the caller, methodA of the Service called, and methodA of the Service called methodB

A) the propagation attribute of methodA is required and that of methodB is required. The Code is as follows:

Java code

1. Public void methodA (){
2. Try {
3. MethodB ();
4. } Catch (Exception e ){
5. Process ();
6. }
7. OtherOperation;
8. }

Assuming that MethodB throws an exception, what will happen when Consumer calls MethodA?

Consumer encountered an exception when calling MethodA. UnexpectedRollbackException: "Transaction rolled back because it has been marked as rollback-only ". Why?

After searching online, I finally found a reasonable explanation. When MethodA calls MethodB and both methods are the required attribute, methodA and methodB share a transaction. When methodB throws an exception, the shared transaction is rolled back, but it is caught by MethodA, if MethodA does not throw an exception in time, it will commit the transaction until the final execution of MethodA normally, but the transaction has been rolled back, so the above exception occurs.

 

In this case, the younger brother started to YY. Which situations will the caller not have this exception? After the collision with the thinking of our friends, we found several methods.

B) MethodA does not add transactions, so it will not commit after execution. Both SUPPORTS and NOT_SUPPORTED can implement this function.

C) The MethodB settings do not share transactions and have their own separate transactions. Verification found that REQUIRES_NEW can implement this function.

Then YY again. Since a rollback transaction cannot be committed, can the rollback transaction be rolled back again?

D) MethodA calls MethodB. If MethodA does not catch MethodB, what will happen to the caller? Of course, the exception of MethodB is caught directly, but it doesn't feel like this scenario can fully reflect whether the transaction with the initial rollback can be rolled back repeatedly. The Code is as follows:

Java code

1. Public void methodA (){
2. MethodB ();
3. OtherOperation;
4. }

 

E) What other scenarios can I use to simulate rollback transactions? The Code is as follows:

Java code

1. Public void methodA (){
2. Try {
3. MethodB ();
4. } Catch (Exception e ){
5. Process ();
6. }
7. Try {
8. MethodB ();
9. } Catch (Exception e ){
10. Process ();
11. }
12. System. out. println ("**************");
13. OtherOperation;
14. }

The first MethodB has rolled back the shared transaction, and the second MethodB will also throw an exception to roll back the shared transaction if the System. the transaction can be rolled back multiple times. The test found that the following SysOut content is printed out, so it is suggested that if the transaction has been rolled back in this way, it will be skipped directly.