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

What is the method of calling the same kind of method in the spring service layer? for this question, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

There is such an interview question: can their transactions take effect when calling methods from other service layers in the service layer; and can their transactions take effect if methods with @ Transactional annotations are called in the same class?

After watching a lot of great gods' blog, let's make a summary today:

First of all, let's give you the answer:

Method calls between different classes, such as method a () of class A calling method b () of class B, in which case transactions work normally. As long as the method a () or b () is configured with a transaction, the transaction is opened and a proxy is generated during the run (note that it is a different class. If the class A method a () invokes class A method b (), then only a () configured transaction will be valid).

Method calls within the same class will not take effect when called, regardless of whether the called b () method has a transaction configured or not.

(1) first of all, let's talk about the detailed explanation of Spring transaction management: the following blog is very clear, from the basic principles, the characteristics of transactions, the isolation level and the three ways of transaction implementation.

Details of Spring transaction Management

Https://blog.csdn.net/donggua3694857/article/details/69858827

(2) after knowing some knowledge of the transaction, let's talk about the @ Transactional note (let's focus on the interpretation of Article 456).

1. Add @ Transactional annotations where transaction management is needed. The @ Transactional annotation can be applied to interface definitions and interface methods, class definitions, and class public methods. 2.@Transactional annotations can only be applied to the method of public visibility. If you use the @ Transactional annotation on a protected, private, or package-visible method, it will not report an error, but this annotated method will not show the configured transaction settings. 3. Note that the mere appearance of the @ Transactional annotation is not enough to start the transaction behavior, it is just a kind of metadata. You must use configuration elements in the configuration file to really turn on the transaction behavior. (in the spring configuration file, open declarative transactions) for example, you can configure: 4. Controls whether interface-based or class-based proxies are created by the value of the "proxy-target-class" attribute of the element. If the "proxy-target-class" attribute value is set to "true", then the class-based proxy will work (in this case, the CGLIB library cglib.jar is required in CLASSPATH). If the "proxy-target-class" attribute is set to "false" or if this property is omitted, the standard JDK interface-based proxy will work. The 5.Spring team recommends using @ Transactional annotations on specific classes (or methods of classes), rather than on any interfaces that the class is intended to implement. Using the @ Transactional annotation on an interface takes effect only if you have set up an interface-based proxy. Because annotations are not inheritable, this means that if a class-based proxy is being used, the transaction settings will not be recognized by the class-based proxy, and the object will not be wrapped by the transaction proxy. 6.@Transactional transactions are started, and either interface-based or class-based proxies are created. So when one transactional method in the same class uses another transactional method, the transaction will not work. If another method with a transaction is called in a method with a transaction, the transaction works and the transaction is shared. If another method without a transaction is called in a method with a transaction, the transaction will also work.

Reasons why it does not take effect:

When the method a () that does not add a transaction is called from outside the class, the serviceImpl object obtained from the spring container is actually the wrapped proxy object, so the object calling the a () method is a dynamic proxy object. In the process of calling b () within the class a (), the code that is actually executed is this.b (), where the this object is the actual serviceImpl object rather than the proxy object that should have been generated, so the b () method is called directly.

Solution:

1. Put it in a different class and call 2. Add configuration 3. 0 to the spring configuration file. Replace the method previously called with a proxy call ((TestService) AopContext.currentProxy ()) .testTransactional2 (); get the proxy class of TestService, then call the transaction method, force through the proxy class, and activate the transaction aspect. 4. Use asynchronous operation, open another thread or write this message to the queue, and deal with the questions in other places about what the spring service layer calls the methods in the same class. I hope the above content can be of some help to everyone. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

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.