Http://blog.sina.com.cn/s/blog_8f61307b0100ynfb.html
Well, the author is also reproduced.
————————————————————————————————————————————————————————————————————————————————————
This article I copied from the Iteye, read it, feel very deep, decided to copy him, to the original author to express gratitude.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~This article is based on the 3.0+ version only as a test)Assume that two transaction managers are defined in a spring container:Transactionmanagerx,Transactionmanagery, in charge of two data sources Datasourcex and Datasourcey. <tx:annotation-driven transaction-manager= "Transactionmanagerx"/><tx:annotation-driven The transaction-manager= "Transactionmanagery"/> (the order of definition in the spring container) has the following application code: public interface Testentityservice { public void Methodx ();p ublic void Methody (); Interface Implementation Classes 1public classTestentityserviceimpl implements Testentityservice {The actual operation of the @Resourceprivate Testentitydao testentitydao;//isDatasourcex.@Transactionalpublic void Methodx () {testentitydao.xxx (); testentitydao.zzz ();} public void Methody () {}} Interface implementation class 2publicAnothertestentityserviceimpl implements Testentityservice {The actual operation of the @Resourceprivate Testentitydao anothertestentitydao;//isDatasourcey.@Transactionalpublic void Methodx () {testentitydao.mmm (); testentitydao.nnn ();} public void Methody () {}} assumes that the method Methodx requires transaction control, and usually we add @transactional annotations directly on the method. However, it seems that the transactional annotation before spring3.0 (the specific version is not clear) does not support distinguishing which transaction manager to use. Version transactional after 3.0 adds a string type of Value property to be distinguished by a special designation. For example @transactional ("aaaaa "), which is the required spring to manage transactions with the id="aaaaa "transaction manager. This property can also be omitted (omitted, with the default TransactionManager in the container) For the use of this property, the following tests are done to
| METHODX () transaction Effective test results |
@Transactional ("Transactionmanagerx") |
@Transactional ("Transactionmanagery") |
@Transactional ("Transactionmanagerz") Transactionmanagerz for undefined |
@Transactional |
| testentityserviceimpl (actual use Datasourcex) |
Y |
| anothertestentityserviceimpl (actual use Datasourcey) |
N |
If you change the order in which two transaction managers are defined in a container, such as <tx:annotation-driven transaction-manager= "Transactionmanagery"/><TX: Annotation-driven transaction-manager= "Transactionmanagerx"/> Get results
| METHODX () transaction Effective test results |
@Transactional ("Transactionmanagerx") |
@Transactional ("Transactionmanagery") |
@Transactional ("Transactionmanagerz") Transactionmanagerz for undefined |
@Transactional |
| testentityserviceimpl (actual use Datasourcex) |
N |
| anothertestentityserviceimpl (actual use Datasourcey) |
Y |
analysis Results (in fact the source can be reflected): container specifies a default transaction manager 1.transaction control is normal when the transaction manager that needs to be used is correctly specified in @transactional ("xxx"). 2. If @transactional specifies a transaction manager that is not defined, spring is handled by default transaction manager. (If the program is using the same data source as the default transaction manager, the transaction control will take effect). 3. If @transactional does not specify a transaction manager, use the default. 4. If the @transactional specifies a mismatched transaction manager (the data source that is actually used is inconsistent with the data source that is controlled by the specified transaction manager), the transaction control is invalidated.Note: The Spring container default transaction manager: Load in order, first loaded as default. For exampleIf <tx:annotation-driven transaction-manager= "Transactionmanagerx"/><tx:annotation-driven Transaction-manager= the "transactionmanagery"/> is defined in the same file, the first Transactionmanagerx as the default. defined in different files, then by the load order of the files, first loaded as default.Recommendation: When @transactional is needed in the actual code, even if there is only one transactionmanager by default, @Transactional will also indicate it. In order to improve the readability of the code after the new data source, in addition to prevent the definition of multiple data sources, the previous default is not by spring defaults to default (such as the day on the line to define a new data source, just the new definition of the TransactionManager is loaded first, it is tragic. ) two. Bean configuration using<bean id= "Testentityservice" class= "Com.xxx.impl.TestEntityServiceImpl"/> Spring will be used by the jdkdynamicaopproxy generated by the proxy class. The effect of this usage is the same as that used in the configuration below. are provided by the Jdkdynamicaopproxy build proxy object. I think the difference is that the following method is not good for code readability in transaction control, because which method requires transaction control and control granularity is in the configuration file, and the code is separated. <bean id= "TestEntityService3" class= " Org.springframework.transaction.interceptor.TransactionProxyFactoryBean "> < Property name= "TransactionManager" ref= "Transactionmanagerx" /> <property name= "Target" > <bean class= " Com.xxxx.impl.TestEntityServiceImpl " /> </property> <property name= "Proxyinterfaces" value= "Com.xxxx.TestEntityService"/> <property name= "Transactionattributes" > <props> <prop key= "*" >PROPAGATION_REQUIRED</prop> </props> </property></bean> The visibility of the method and the @Transactional @transactional annotations should only be applied to the public visibility method. If you use @Transactional annotations on protected, private , or package-visible methods, it will not be an error, However, this annotated method will not show the configured transaction settings. @Transactional Annotations can be applied to interface definitions and interface methods, class definitions, and class public methods. Note, however, that only @Transactional annotations appear to be less than open transaction behavior, and that it is only a meta-data that can be recognized @Transactional Annotations and the configuration described above are appropriate for use with beans that have transactional behavior. In the above example, it is actually the presence opening transaction behavior of the <tx:annotation-driven/> element. The spring team's recommendation is that you use @Transactional annotations on specific classes (or methods of classes) rather than on any interface that the class implements. You can certainly use @Transactional annotations on the interface, but this will only take effect if you set up an interface-based proxy. Because annotations are cannot inherit . In real-world development, most prefer to extract the persisted operation's code into another method (because the business code that does not want the transaction to be extended too long) and then add @transactional to the extracted method, the result is that the extracted code, even if the transaction tag is added, There is also no effect on transaction control (both private and public). For example: Public class testentityserviceimpl implements testentityservice {@Resourceprivate testentitydao testentitydao;//The actual operation is Datasourcex. @Transactionalpublic void methodx () {testentitydao.xxx (); testentitydao.zzz ();} Public void methody () {methodx () } if Testentityservice.methody () is executed and the transaction does not take effect. Only Testentityservice.methody () is effective. From the principles of spring implementation (dynamic proxies and AOP), only external calls are intercepted, and internal calls to methods are usually not supported by AOP. From the Internet to an article, you can solve the problem.http://blog.csdn.net/quzishen/archive/2010/08/11/5803721.aspx
Spring's Annotation-driven configuration transaction manager detailed
