java stereotyped series - spring transaction failure scenario

Before explaining the transaction failure scenario, we need to introduce AOP first, because @Transactionit is implemented through AOP.

AOP is actually a proxy object that generates bean objects. When the bean is created and initialized, if it is a method with transaction annotations, it will be enhanced to form a proxy class. In spring, there are two ways of dynamic proxy:

• JDK dynamic proxy: put the original object inside the proxy object, and realize the original business logic by calling the included original object, which is a decorator mode. Private, protected, and final methods must not be proxied, because interfaces do not support them. In addition, static methods are not supported.
• CGLIB dynamic proxy: it generates a subclass of the original object, and the subclass overrides the method of the parent class to enhance the parent class.
  • Private methods must not be proxied, because neither subclasses nor other classes can access a class's private methods.
  • The protected method can be proxied, but CGLIB is implemented based on the inheritance relationship. The protected proxy method in the generated proxy class is also protected, and the access scope is limited.
  • Final modified methods cannot be proxied because final modified methods cannot be overridden by subclasses. Final modified classes cannot be proxied, because final modified classes cannot be inherited.
  • Static methods cannot be proxied.

The spring transaction failure scenario is as follows:

• The method is a final method or a non-public method: spring requires that the proxied method must be public and not final modified, because AOP does not support
• Internal call of the method: the method has the ability of transactions because AOP generates a proxy object, but if the method is called internally, the proxy object will not be used, so there will be no transaction
• Not managed by spring: not managed by spring and will not be enhanced by AOP
• Unopened transaction: You need to use annotations in the entry class @EnableTransactionManagementto open the transaction
• The table does not support transactions: the default storage engine before MySQL5.5 is Myisam, and Myisam does not support transactions. If the database used does not support transactions, then naturally the transaction function cannot be used
• The transaction propagation type of the method does not support transactions: If the transaction propagation type of the internal method is a propagation type that does not support transactions, the transaction of the internal method will also fail in Spring, such as@Transactional(propagation = Propagation.NOT_SUPPORTED)
• Wrong annotation exception type: If @Transactionalthe wrong exception type is annotated in the annotation, the rollback of the Spring transaction will be invalid. The transaction exception type for the default rollback in Spring is RuntimeException. If the code throws an Exception exception, the transaction cannot be caught. Of course, you can manually set rollbackForproperties to catch specified exceptions.
• Incorrectly caught exception: If the exception in the method is caught and processed by try-catch in the method, the exception will not be passed up and the transaction will not be triggered
• Multi-thread call problem: If a new thread is enabled to execute SQL operations within the method, it will not be rolled back. Spring's transactions are thread-safe through ThreadLocal. Transactions are bound to the current thread, and multiple threads will naturally invalidate transactions.

If you are interested in learning more about it, please visit my personal website: Yetong Space