Spring declarative transaction annotation @Transactional

Use @Transactional

There are a few points to note here:

• A. Whether a function needs affairs, it must be considered in design and coding. You can't just complete the basic functions.
• B. If a transaction is added, the development environment must be tested (the test environment also tries to trigger exceptions and test rollbacks) to ensure that the transaction takes effect.
• C. Please pay attention to the matters needing attention in the process of using the business as follows.

1. Do not declare @Transactional on the interface  , but use @Transactional  annotations on methods of specific classes  , otherwise the annotations may be invalid.
2. Don't try to save trouble. Put @Transactional in the class-level declaration. Putting it in the class declaration will make all methods have transactions. Therefore, @Transactional should be placed at the method level. If you do not need to use transaction methods, do not place transactions, such as query methods. Otherwise it will have an impact on performance.
3. The @Transactional method is used, and @Transactional is invalid for calling methods in the same class. For example, there is a class Test with a method A, and A then calls method B of the Test class (regardless of whether B is public or private), but A does not declare an annotation transaction, and B does. After calling A externally, B's transaction will not work. (I often make mistakes here)
   Since the internal method is called using this. instead of a bean managed by spring, AOP cannot be implemented through proxy weaving. To solve this problem, you can call it through the ApplicationContext to obtain the bean.
4. The method using @Transactional can only be public. The method annotated by @Transactional is only valid when called by other external classes, so it can only be public. The reason is related to the above. Therefore, using @Transactional annotation on protected, private or package-visible methods, it will not report an error, but the transaction is invalid.
5. After testing in ICORE-CLAIM, the effect is as follows:
   * Throw the checked exception XXXException, the transaction will be rolled back.
   * Throw the runtime exception NullPointerException, the transaction will be rolled back.
   * In Quartz, the @Transactional method is added to execute directly, which can be rolled back; the indirect call does not roll back. (That is mentioned in point 3 above)
   * In asynchronous tasks, execute directly calls and adds the @Transactional method, which can be rolled back; indirect calls will not roll back. (That is mentioned in point 3 above)
   * Add @Transactional to action, it will not roll back. Remember not to add transactions to the action.
   * Add @Transactional to the service, if the method is directly transferred by the action, it will be rolled back, if it is indirectly transferred, it will not be rolled back. (That is mentioned in 3 above)
   * Add @Transactional to the private in the service, the transaction will not be rolled back.