(12) Spring from the beginning to the ground — Spring transactions

The Spring transaction

A transaction is a logical set of operations that either all or none of them execute

Properties of transactions (ACID)

• atomic
• consistency
• Isolation,
• persistence

Spring manages transactions in several ways

Whether the program supports transactions depends on whether the database supports transactions

How MySQL guarantees atomicity:

The recovery mechanism relies on rollback logs

• Programmatic transactions, hard-coded in code (not recommended)

• Declarative transactions, configured in configuration files (recommended), less intrusive code, implemented via AOP

• • Declarative TRANSACTIONS based on XML
  • Annotation-based declarative transactions

Introduction to Spring transaction Management interface

The three most important interfaces related to transaction management in Spring are as follows

• PlatformTransactionManager (platform) transaction manager, Spring transaction strategy core (upper management)
• TransactionDefinition: TransactionDefinition information (transaction isolation level, propagation behavior, timeout, read only, rollback rule)
• TransactionStatus: Transaction running status

PlatformTransactionManager: transaction management interface

Spring does not manage transactions directly, but provides a variety of transaction managers. Spring provides transaction managers for multiple platforms through this transaction management interface, and the implementation is up to each platform.

This interface is mainly to abstract out the transaction management behavior, and then different platforms to implement it, can ensure that the behavior provided to the external is unchanged, convenient for us to extend.

TransactionDefinition: Transaction attribute

This class defines some basic transaction properties.

• Transaction attributes include five aspects

• • Isolation level
  • Propagation behavior
  • Rollback rules
  • Whether the read-only
  • Transaction timeout

TransactionStatus: TransactionStatus

This interface is used to record the state of a transaction. This interface defines a set of methods to obtain or determine the corresponding state information of a transaction.

public interface TransactionStatus{ boolean isNewTransaction(); // New transaction Boolean hasSavepoint(); Void setRollbackOnly(); // Set to rollback only Boolean isRollbackOnly(); // Whether only Boolean isCompleted is rolled back; }}Copy the code

Transaction attributes explained in detail

Spring transaction Propagation behavior (enumerated classes: Propagation)

Transaction propagation behavior is designed to solve the problem of transactions that call each other between business layers.

When a transaction method is called by another transaction method, you must specify how the transaction should be propagated. For example, a method may continue to run in an existing transaction, or it may start a new transaction and run in its own transaction.

Isolation level in Spring transactions (Enumeration class: Isolation)

Five constants representing the isolation level are defined in the TransactionDefinition interface.

• ISOLATION_DEFAULT: default isolation level of the back-end database. REPEATABLE_READ isolation level adopted by Mysql READ_COMMITTED isolation level adopted by Oracle.
• ISOLATION_READ_UNCOMMITTED: Minimum isolation level that allows uncommitted data changes to be read, possibly resulting in dirty reads, illusory reads, or unrepeatable reads
• ISOLATION_READ_COMMITTED: Allows concurrent transactions to read data that has already been committed. Dirty reads can be prevented, but phantom or unrepeatable reads can still occur
• ISOLATION_REPEATABLE_READ: Multiple reads of the same field are consistent, unless the data is modified by the transaction itself. This can prevent dirty reads and unrepeatable reads, but phantom reads are still possible.
• ISOLATION_SERIALIZABLE: Highest isolation level, fully subject to ACID isolation level. All transactions are executed one by one so that interference between transactions is completely impossible. That is, this level prevents dirty reads, unrepeatable reads, and phantom reads. But this severely affects the performance of the program. This level is also not typically used.

Transaction timeout attribute

A transaction timeout is the maximum time that a transaction is allowed to execute, and if the transaction has not completed after this time, the transaction is automatically rolled back. The timeout period in TransactionDefinition is represented by an int in seconds. The default value is -1

Transaction read-only attribute

For transactions that only read data queries, you can specify a transaction type of Readonly, that is, a read-only property. Read-only transactions do not involve data modification, and the database provides some optimizations suitable for methods that have multiple database query operations.

MySQL by default enables autoCOMMIT mode for each newly established connection. In this mode, each SQL statement sent to the MySQL server is processed in a separate transaction, which automatically commits and starts a new transaction.

If Transaction is not added, each SQL entry will start a separate Transaction, and the data changed by other transactions will be read in real time.

If you execute multiple queries, statistical query, for example, the report query, in this scenario, the multiple query SQL must ensure that the overall read consistency, otherwise, after the SQL query of the preceding article, the article after the SQL query, data changes by other users, then the total time of statistics query will be read data inconsistent state, at this time, Transaction support should be enabled

Transaction rollback rules

These rules define which exceptions will cause the transaction to roll back and which will not. By default, a transaction is rolled back only if it encounters a RuntimeException (a subclass of RuntimeException). Error also causes the transaction to roll back, but not if it encounters a Checked exception.

You can do this if you want to define the type of exception you want to roll back

@Transactional(rollbackFor = MyException.class)
Copy the code

@ Transaction annotations

scope

• Methods: It is recommended to use annotations on methods, but it is important to note that this annotation can only be applied to public methods, otherwise it will not take effect
• Class: If defined on a class, all public methods in that class are valid
• Interface: This parameter is not recommended for interfaces

Common Configuration Parameters

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Transactional {

    @AliasFor("transactionManager")
    String value() default "";

    @AliasFor("value")
    String transactionManager() default "";

    Propagation propagation() default Propagation.REQUIRED;

    Isolation isolation() default Isolation.DEFAULT;

    int timeout() default TransactionDefinition.TIMEOUT_DEFAULT;

    boolean readOnly() default false;

    Class<? extends Throwable>[] rollbackFor() default {};

    String[] rollbackForClassName() default {};

    Class<? extends Throwable>[] noRollbackFor() default {};

    String[] noRollbackForClassName() default {};

}
Copy the code

Summary of common configuration parameters for @Transactional

Transaction Transaction annotation principle

The working mechanism of @Transaction is implemented based on AOP, which is sometimes implemented using dynamic proxies. The JDK dynamic proxy is used by default if the target object implements the interface, and Cglib is used for dynamic proxy if the object does not implement the interface

The createAopProxy() method determines whether to use the JDK or Cglib for dynamic proxies

If a class or a public method of a class is annotated with the @Transaction annotation, the Spring container creates a proxy class for it at startup. When the @Transaction annotation public method is called, The invoke method of the TransactionInterceptor class is actually called. This method starts the transaction before the target method, rolls back the transaction if an exception occurs during the method execution, and commits the transaction after the method call completes.

Annotation failure

Apply to methods that are not public

Spring AOP self-invocation problem

If another method in the same class without the @Transaction annotation internally calls the @Transaction annotated method, the Transaction of the @Transaction annotated method will be invalidated.

This is due to the Spring AOP proxy, because Spring Transaction management only takes effect when the @Transaction annotated method is called outside of the class.

The solution is to avoid self-invoking or using AspectJ instead of Spring AOP proxies in the same class.

The propagation properties are incorrectly set

The rollbackFor property is incorrectly set

No exception is thrown in a try/catch to invalidate it

The database does not support transactions

The last

• I hope you can give me a thumbs up if you feel that you have gained something after watching it. This will be the biggest motivation for me to update. Thank you for your support
• Welcome everyone to pay attention to my public number [Java tomb Fox], focus on Java and computer basic knowledge, to ensure that you see something harvest, do not believe you hit me
• If you have different opinions or suggestions after reading, welcome to comment together. Thank you for your support and kindness.

I’m Tsuka Fox. I love programming as much as you do.

Please follow the public account “Java Tomb Fox” for the latest news