Spring~ Transaction API, Causes of Transaction Failure, Transaction Propagation Features

Spring transaction

Spring transactions are encapsulated and extended based on the database transaction used. The
encapsulation is mainly to encapsulate some JDBC write transaction objects. The extension mainly has the following characteristics

1. Added the concept of transaction propagation, which is much simpler than programmatic transactions in terms of code logic
2. Provide declarative transactions or annotated configuration transactions to separate business code from transactions and make transactions easier to use (AOP technology)

However, it also caused the occurrence of transaction failure. The specific reasons are described below

Transaction API

Spring provides a TransactionDefinition , which defines the isolation level and propagation characteristics of the transaction. The

default isolation level is DEFAULT, which is the isolation level of the database by default.

The propagation feature is required by default, which means that if it is added, it will be created if it is not.

A transaction manager PlatformTransactionManager is also specifically defined , which provides commit submission and rollback rollback operations of the transaction, and a method to obtain the state of the transaction at this time. The state of the

transaction has the following as the

name implies, such as whether it is a new transaction, whether Has been submitted, has it been rolled back, has it been completed

one leftThe most important TransactionInterceptor, And TransactionInterceptor implements MethodInterceptor , which means method interception. When we want to execute the method configured with the transaction, the method will be intercepted. After intercepting the method configured with the transaction, it will be processed under TransactionAspectSupport under TransactionAspectSupport . AOP) In

most cases, it is very convenient to use the annotation @Transactional to achieve transaction support, and some properties can be configured

1. name
   When there are multiple TransactionManagers in the configuration file, you can use this attribute to specify which transaction manager to select.

2. The propagation
   behavior of the propagation transaction, the default value is REQUIRED.

3. 
   The isolation degree of isolation transaction, the default value adopts DEFAULT.

4. timeout
   timeout transaction, a default value is -1. If the time limit is exceeded but the transaction has not been completed, the transaction is automatically rolled back.

5. read-only
   specifies whether the transaction is a read-only transaction, the default value is false; in order to ignore those methods that do not require transactions, such as reading data, you can set read-only to true.

6. rollback-for is
   used to specify the type of exception that can trigger transaction rollback. If there are multiple exception types that need to be specified, each type can be separated by a comma.

7. no-rollback-for
   throws the exception type specified by no-rollback-for and does not roll back the transaction.

Realization principle

The realization principle of this is still the way of dynamic proxy. Based on CGLib dynamic proxy, the core is to use interceptor. It is TransactionInterceptor.

TransactionInterceptor implements MethodInterceptor, so the method annotated by @Transactional will be intercepted by TransactionInterceptor, and then the invoke method is called. The TransactionDefinition is initialized according to the attributes configured by @Transactional, and TransactionManager will have more attributes to determine whether it is get or new. This is based on the propagation characteristics of the transaction. To check, TransactionManager has a method to obtain the status of the transaction at this time, and it is also convenient to judge whether it will eventually call the TransactionAspectSupport method to achieve enhancement.

Transaction failure

Whether the bean is managed by Spring, or whether the bean is proxied

Whether the method is public

Does the database support transactions

Is the method modified by static or final

Whether it is a transaction failure caused by the internal call of the method

Whether the exception was caught

Whether the exception conforms to the specification, the default is runtimeException

Transaction propagation mechanism

• Commonly used transaction propagation mechanism

PROPAGATION_REQUIRED
is also the default propagation mechanism;

PROPAGATION_REQUIRES_NEW
always initiates a new transaction. This propagation mechanism is suitable for operations that are not affected by the parent method transaction. For
example, in some business scenarios, business logs need to be recorded for asynchronous reverse inspections. Then, regardless of whether the main business logic is completed, the log needs to be recorded In the end, the log cannot be lost because the main business logic reports an error;

PROPAGATION_NOT_SUPPORTED
does not use transactions, it
can be used to send reminder messages, station delivery, SMS, email reminders, etc. It does not belong to and should not affect the main business logic, and the main business logic should not be rolled back even if the delivery fails.