本文仅基于3.0+版本作为测试)
假定spring
容器中定义了两个事务管理器:
transactionManagerX,
transactionManagerY,分管两个数据源datasourceX和datasourceY.
<tx:annotation-driven
transaction-manager="transactionManagerX"
/>
<tx:annotation-driven
transaction-manager="transactionManagerY"
/>
(spring容器中的定义顺序如上)
有如下应用代码:
public
interface
TestEntityService
{
public
void
methodX();
public
void
methodY();
}
接口实现类1
public
class
TestEntityServiceImpl
implements
TestEntityService
{
@Resource
private
TestEntityDao
testEntityDao;//实际操作的是
datasourceX.
@Transactional
public
void
methodX()
{
testEntityDao.xxx();
testEntityDao.zzz();
}
public
void
methodY()
{
}
}
public
class
AnotherTestEntityServiceImpl
implements
TestEntityService
{
@Resource
private
TestEntityDao
anOtherTestEntityDao;//实际操作的是
datasourceY.
@Transactional
public
void
methodX()
{
testEntityDao.mmm();
testEntityDao.nnn();
}
public
void
methodY()
{
}
}
假设方法methodX需要事务控制的,通常我们是直接在方法上添加@Transactional标注,
但是好像spring3.0(具体版本没弄清)之前的Transactional标注不支持区分使用哪个事务管理器。3.0之后的版本Transactional增加了个string类型的value属性来特殊指定加以区分。
例如@Transactional("
aaaaa"),即显示的要求spring用id="
aaaaa"的事务管理器来管理事务。该属性亦可省略(省略的话用容器中缺省的transactionManager)
对于该属性的用法做了如下测试来
methodX()事务生效测试结果 |
@Transactional
|
@Transactional
|
@Transactional
("transactionManagerZ")
transactionManagerZ为未定义过的
| @Transactional |
TestEntityServiceImpl(实际使用datasourceX) | Y | N | Y | Y |
AnotherTestEntityServiceImpl (实际使用datasourceY) | N | Y | N | N |
如果调换两个事务管理器在容器中的定义顺序,如
<tx:annotation-driven
transaction-manager="transactionManagerY"
/>
<tx:annotation-driven
transaction-manager="transactionManagerX"
/>
得到的结果
methodX()事务生效测试结果 |
@Transactional
|
@Transactional
|
@Transactional
("transactionManagerZ")
transactionManagerZ为未定义过的
| @Transactional |
TestEntityServiceImpl(实际使用datasourceX) | Y | N | N | N |
AnotherTestEntityServiceImpl (实际使用datasourceY) | N | Y | Y | Y |
分析结果(其实源码就可以反应出):容器指定一个默认的事务管理器
1.当在@Transactional("xxx")中正确指定了需要使用的事务管理器时,事务控制正常。
2.如果@Transactional指定了未定义过的事务管理器,spring以缺省默认的事务管理器来处理。(如果程序正好使用的是缺省事务管理器同一个数据源,事务控制将生效)。
3.如果@Transactional不指定事务管理器,使用缺省。
4.如果@Transactional指定了不匹配的事务管理器(实际用到的数据源和指定的事务管理器控制的数据源不一致),事务控制将失效.
注:spring容器缺省事务管理器:以加载顺序,首先加载的作为缺省。例如
如果
<tx:annotation-driven
transaction-manager="transactionManagerX"
/>
<tx:annotation-driven
transaction-manager="transactionManagerY"
/>
定义在同一个文件中,则第一个transactionManagerX作为缺省。
定义在不同文件,则按文件的加载顺序,首先加载的作为缺省。
建议:实际代码中需要用到@Transactional时,即使默认只有一个transactionManager,@Transactional也将其标明。以提高新增数据源后代码可读性,另外防止定义多个数据源后,以前缺省的不被spring默认为缺省了(比如哪天上线新定义了一个数据源,刚好新定义的transactionManager被先加载了,那就悲剧了。)
二.bean的配置使用
容器中加了<tx:annotation-driven
>(需要增加一些xsd)之后,需要事务控制的的service,不需要再具体的bean上做其他的配置,例如用代理包装。直接配置即可
<bean
id="testEntityService"
class="com.xxx.impl.TestEntityServiceImpl"/>
spring将由JdkDynamicAopProxy 生成代理过的类提供使用。
这种用法的效果和下面配置使用效果一样。都是由JdkDynamicAopProxy 生成代理对象提供使用。
我觉得区别是下面的方法在事务控制的代码可读性上不好,因为哪个方法需要事务控制和控制粒度都在配置文件中,和代码分开了。
<bean
id="testEntityService3"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryB
ean">
<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>
方法的可见度和
@Transactional
@Transactional
注解应该只被应用到
public
可见度的方法上。
如果你在
protected、private
或者
package-visible
的方法上使用
@Transactional
注解,它也不会报错,
但是这个被注解的方法将不会展示已配置的事务设置。
@Transactional
注解可以被应用于接口定义和接口方法、类定义和类的
public
方法上。然而,请注意仅仅
@Transactional
注解的出现不足于开启事务行为,它仅仅
是一种元数据,能够被可以识别
@Transactional
注解和上述的配置适当的具有事务行为的beans所使用。上面的例子中,其实正是
<tx:annotation-driven/>元素的出现
开启
了事务行为。
Spring团队的建议是你在具体的类(或类的方法)上使用
@Transactional
注解,而不要使用在类所要实现的任何接口上。你当然可以在接口上使用
@Transactional
注解,但是这将只能当你设置了基于接口的代理时它才生效。因为注解是
不能继承
的。
实际开发中,多半喜欢将持久化操作的代码集中抽出为另一个方法(因为不想事务被无关的业务代码托的持续太长),然后在抽取出来的方法上加上@Transactional,这样的结果是被抽离出的代码即使加了事务标记,也根本起不到事务控制的效果(不管是private和public)。
例如:
public
class
TestEntityServiceImpl
implements
TestEntityService
{
@Resource
private
TestEntityDao
testEntityDao;//实际操作的是datasourceX.
@Transactional
public
void
methodX()
{
testEntityDao.xxx();
testEntityDao.zzz();
}
public
void
methodY()
{
methodX()
}
}
如果执行TestEntityService.methodY();事务是不生效的。只有TestEntityService.methodY();才生效。
从spring实现这些的原理(动态代理和aop)上来看,只拦截外部调用,方法的内部调用通常是不被aop支持的。
从网上扒到一篇文章,可以解决这个问
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://blog.csdn.net/quzishen/article/details/5803721
拦截器的实现原理很简单,就是动态代理,实现AOP机制。当外部调用被拦截bean的拦截方法时,可以选择在拦截之前或者之后等条件执行拦截方法之外的逻辑,比如特殊权限验证,参数修正等操作。但是如果现在一个需求是,当外部调用拦截bean的时候,不但要执行拦截当前方法,如果当前方法内部同时调用了其他内部方法,也要被拦截。按照目前的拦截器实现逻辑,是无法拦截当前方法内部调用的方法的,这样说有点抽象,看一个代码:
- public class BeanA{
- public void method1(){
- method2();
- }
- public void method2(){
- ...
- }
- }
当外部调用beanA.method1();的时候,拦截器执行拦截逻辑,执行完毕后进入method1方法执行,当调用method2的时候,拦截器是否会再次拦截?是不会的,这里涉及到拦截器的一个原理,拦截器涉及两个对象,代理对象和原始对象,拦截器所执行的代理对象执行完毕后,当执行method1即进入了原始对象,那么在原始对象中调用method2,是无法进行拦截的。所以很显眼,这样无法满足我们的需求。
在spring的源代码中通过一个增强对象的检查,控制了当前的内部调用是否使用代理来执行,这让人感到无奈。spring的作者们很隐晦的提出避免内部调用的方法。
我们可能会想,在外部调用两次beanA,第一次调用method1,第二次调用method2,这样做可以解决问题,但是这样的直接后果是我们的逻辑代码将变得紊乱,并非所有的场景下都可以通过这样的设计来完成。虽然这是spring官方推荐的避免内部调用的idea。
查看了相关资料,得到了一种方法,即在method1的内部,通过直接获取当前代理对象的方式然后通过代理对象调用method2,这样触发拦截。
看看代码:
- public void method1(){
- logger.error("1");
-
-
- if(null != AopContext.currentProxy()){
- ((NorQuickNewsDAO)AopContext.currentProxy()).method2();
- }else{
- method2();
- }
- }
-
- public void method2(){
- logger.error("2");
- }
我们显示的调用了AopContext来获取当前代理对象,然后调用其方法,这样做还必须的一个步骤是将当前的代理暴露给线程使用,在配置文件中需要配置一个参数:
- <property name="exposeProxy">
- <value>true</value>
- </property>
它是ProxyConfig的一个参数,默认是false,如果不设置这个参数,那么上述java代码将无法获取当前线程中的代理对象。
这种方法可以成功触发拦截,但是也带来了其他问题,比如代码的织入,我们的代码将变得复杂而且晦涩,而且严格要求系统针对于当前的bean必须配置拦截器,否则会因为找不到拦截器而抛出异常。
这样做有什么负面影响?对事务的影响,对安全的影响,现在不得而知,还需要逐步去测试以尝试。
http://blog.csdn.net/quzishen/article/details/5803721
http://blog.sina.com.cn/s/blog_8f61307b0100ynfb.html