Problem
When you use @Transactional, @Cacheable, or custom AOP annotations in spring, other methods that use the AOP mechanism to invoke the object in the object's internal methods are invalidated.
@Transactional public void saveFile(FileDetail sourceFile, FileDetail targetFile, FileRelation fileRelation) { sourceFile = fileDao.queryFileByMd5(sourceFile.getMd5()); fileDao.insertFile(sourceFile); fileRelationDao.insertFileRelation(fileRelation); sendMessage(); } public void sendMessage(){ System.out.println("打日志"); System.out.println("发送消息..."); }
Method-level calls in the same class can also cause AOP annotations to fail
Reason
Spring AOP uses the JDK dynamic proxy and cglib, because there are no interface classes, so the Cglib proxy is used. When the method is proxied, the proxy object is actually generated through the dynamic proxy, and then the proxy object executes the Invoke method, which performs other operations when invoking the method of the Proxied object. The problem is that when other methods of the proxy object are called in the method of the proxy object, the proxy object itself, not the proxy object, is used. This causes a method to be invoked when the proxy object is called, and one that is called by the proxy object. Their calls are not always out of the same object.
Instance
(1) When we call SaveFile (), Spring's dynamic agent dynamically generates a proxy object (Servicefile).
(2) When we call SaveFile, it is actually a servicefile call.
(3) When calling another annotation method SendMessage of the same class within the SaveFile () method, it is actually using this.savefile (), and this refers to the current object and not to the proxy object, so the annotations are invalidated.
Solution Solutions
Gets the current proxy object through Aopcontext.currentproxy ().
1.aopcontext.currentproxy ();
2. Modify the XML
@Transactional public void saveFile(FileDetail sourceFile, FileDetail targetFile, FileRelation fileRelation) { sourceFile = fileDao.queryFileByMd5(sourceFile.getMd5()); fileDao.insertFile(sourceFile); fileRelationDao.insertFileRelation(fileRelation); (FileService)AopContext.currentProxy().sendMessage(); } @Transactional public void sendMessage(){ System.out.println("打日志"); System.out.println("发送消息..."); }
Configuration
<tx:annotation-driven transaction-manager="transactionManager"/><!-- (事务管理)transaction manager, use JtaTransactionManager for global tx --><bean id="transactionManager"class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSourceForSqlServer" /></bean>
Precautions
1. Add @transactional annotations where transaction management is required. @Transactional annotations can be applied to interface definitions and interface methods, class definitions, and public methods of classes.
[Email protected] annotations can only be applied to methods of public visibility. If you use @Transactional annotations on protected, private, or package-visible methods, it will not error, but this annotated method will not show the configured transaction settings.
3. Note that only @Transactional annotations appear to be less than open transaction behavior, which is simply a kind of meta data. The configuration element must be used in the configuration file to actually open the transaction.
4.spring things are based on classes and interfaces so it is only possible to invoke things inside another class within a class, and the method of invoking its own class within the same class is invalid. Spring does not have to be used frequently, and the first table that operates at the same time as the processing of things is restricted (that is, temporarily locked). When the amount of data is large, there will be some impact.
Reference
[1] [Spring AOP annotation invalidation puzzle] (http://blog.csdn.net/u012373815/article/details/77345655)
[2] Spring @Transactional The reason why things are not configured
[3] Does Spring @Transactional attribute work on a private method?
Spring AOP Annotation Invalidation