If a transaction does not take effect, you can find the reasons from the following points:

1. Check if your methods are public. 2. Check whether the method is called in the same class (such as a method calling b method in the same class, on b method added transaction). Is your exception type unchecked? What if I want to check the exception and also want to roll back the exception? I can specify the exception type above the annotation.

@Transactional(rollbackFor=Exception.class) 
1
Copy the code

Similarly, norollbackFor is a custom exception that does not rollback

4, Check your own data engine, if MySQL, note that the table should use a transactional engine, such as InnoDB, if myISam, transactions do not work.

Check all storage engines in MySQL: show engines; Check the current storage engine of MySQL: show variables like ‘%storage_engine%’;

Abnormal is not caught by you

6. If you are an SSM framework and are using XML to configure open transactions, you should look at:

  • Whether annotation parsing is enabled

    <tx:annotation-driven transaction-manager=”transactionManager” proxy-target-class=”true”/> 1

  • Whether Spring has scanned your package? Here is the package scanned to org.test

    <context:component-scan base-package=”org.test” ></context:component-scan> 1

Fourth, knowledge development

1. By default, Spring rolls back transactions to Unchecked exceptions; If it is a checked exception, it is not rolled back. What are checked exceptions and what are unchecked exceptions?

Exceptions derived from Error or RuntimeException (such as null Pointers, 1/0) are called unchecked exceptions in Java. Other exceptions that inherit from Java.lang. Exception are collectively called Checked Exceptions. Such as IOException and TimeoutException

2. Read-only transactions

@Transactional(propagation=Propagation.NOT_SUPPORTED,readOnly=true)
1
Copy the code

The read-only flag is only applied when a transaction is started, otherwise even the configuration is ignored. Starting a transaction increases thread overhead and locks the database for shared reads (depending on the database type and transaction isolation level). Typically, you don’t have to set up read-only transactions to incur additional system overhead just to read data.

3. The difference between programmatic and declarative transactions

See this blog post on the difference between programmatic and declarative transactions:

What is the difference between programmatic and declarative transactions in a SpringBoot project?

What are the database isolation levels

MySQL has four isolation levels:

What are the database isolation levels and what are their meanings? What is the default isolation level for MYSQL?

5. Transaction propagation mode

  • REQUIRED(default mode) : Business methods need to run in a container. If the method is already in a transaction when it runs, join the transaction, or create a new transaction yourself.
  • NOT_SUPPORTED: The declared method does not require a transaction. If the method is not associated with a transaction, the container will not start the transaction for it, and if the method is called within a transaction, the transaction will be suspended, and the original transaction will resume execution after the call.
  • REQUIRESNEW: The method assembly initiates a new transaction for itself, regardless of whether a transaction exists. If the method is already running in a transaction, the original transaction suspends and a new transaction is created.
  • MANDATORY: This method can only be executed in an existing transaction. Business methods cannot initiate their own transactions. The container throws an exception if it is called without a transaction.
  • SUPPORTS: When this method is called within the scope of a transaction, the method becomes part of that transaction. If a method is called outside the scope of the transaction, the method is executed without a transaction.
  • NEVER: This method must NEVER be executed within the scope of a transaction. If yes, throw the exception. The method is executed only if it is not associated with any transactions.
  • NESTED: Runs in a NESTED transaction if an active transaction exists. If there are no active transactions, the REQUIRED attribute is executed. It uses a single transaction that has multiple savepoints that can be rolled back. A rollback of an internal transaction has no effect on an external transaction. It is only right DataSourceTransactionManager transaction manager work.