Shulou(Shulou.com)06/01 Report--

Today, the editor will share with you the relevant knowledge points about how to use the Spring annotation @ Transactional. The content is detailed and the logic is clear. I believe most people still know too much about this knowledge, so share this article for your reference. I hope you can get something after reading this article. Let's take a look at it.

1. Transactional

Declarative transaction management is based on AOP. Its essence is to intercept before and after the method, then create or join a transaction before the target method starts, and commit or roll back the transaction according to execution after the target method is executed.

In short, the @ Transactional annotation can roll back a transaction when there is an error in code execution.

II. Instructions for use

Add @ EnableTransactionManagement annotations to the startup class.

When used on a class, all public methods of that class will have transactional properties of that type, and we can also use this annotation at the method level to override the class-level definition.

In the project, @ Transactional (rollbackFor=Exception.class), if this annotation is added to the class, the method in the class throws an exception and the data in the database is rolled back.

If the rollbackFor attribute is not configured in the @ Transactional annotation, things will only be rolled back when RuntimeException is encountered, and rollbackFor=Exception.class allows things to roll back when they encounter non-runtime exceptions.

III. Invalidation of annotations

Normally, you only need to add @ Transactional annotations to the method, but it is important to note that although it is easy to use, there will still be the problem of annotation invalidation if annotations are used improperly.

@ Transactional is applied to non-public modified methods

The transaction interceptor intercepts before and after the execution of the target method, and internally calls the method to obtain the transaction configuration information annotated by Transactional. Before calling, it checks whether the modifier of the target method is public, and if it is not public, it will not get the attribute configuration information of @ Transactional.

@ Transactional comment property rollbackFor setting error

RollbackFor can specify the type of exception that can trigger a transaction rollback. Spring rolls back the transaction by default when it throws an unchecked unchecked exception (an exception inherited from RuntimeException) or Error; other exceptions do not trigger a rollback transaction. If you throw other types of exceptions in a transaction but expect Spring to roll back the transaction, you need to specify the rollbackFor property.

Method calls in the same class invalidate @ Transactional

In development, it is inevitable to call methods in the same class, for example, there is a class Test, one of its methods, AMagi A, then calls method B of this class (whether method B is decorated with public or private), but method A does not declare annotated transactions, while method B has. After method An is called externally, the transaction of method B will not work. This is also a place where mistakes are often made.

Then why did this happen? In fact, this is due to the use of the Spring AOP proxy, because the transaction method is managed by the proxy object generated by Spring only when the transaction method is called by code other than the current class.

The exception was "eaten" by your catch, causing @ Transactional to fail.

If you manually catch to catch this exception and handle it, the transaction manager will think that the current transaction should be normal commit, which will cause the annotation to fail. If you have to catch and not fail, you must throw new Exception the exception in the code block.

Database engine does not support transactions

The premise of opening a transaction is that it needs the support of the database. The Mysql engine we usually use supports transactions, so this kind of problem generally does not occur.

Transaction management is affected when multithreaded tasks are started

Because threads are not managed by spring, threads cannot use spring transactions by default, nor can they obtain spring-injected bean to start multithreading within methods managed by spring declarative transactions, and methods within multithreads are not controlled by transactions.

In the following code, the insert method is called within the thread, and spring will not add the insert method to the transaction, even if the @ Transactional annotation is added to the insert method, it will not work.

@ Service public class ServiceA {@ Transactional public void threadMethod () {this.insert (); System.out.println ("main insert is over"); for (int axi0; a

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.