transactional注解,分布式事务能用@transactional吗
transactional注解,分布式事务能用@transactional吗详细介绍
本文目录一览: Spring之Transactional注解
该注解的签名如下:
定义零(0)个或多个异常类,这些异常类必须是Throwable的子类,指示哪些异常类型必须导致事务回滚。 默认情况下,事务将在RuntimeException和Error上回滚,但不会在检查型异常(业务异常)上回滚。具体可以看DefaultTransactionAttribute.rollbackOn(Throwable)方法,有比较详细的解释。 这是构造回滚规则(与 rollbackForClassName比较)的首选方法,它匹配异常类及其子类。
定义零(0)个或多个异常名称(对于必须是Throwable子类的异常),指示哪些异常类型必须导致事务回滚。 这可以是完全限定类名的子字符串,目前不支持通配符。例如,“ServletException”的值将与ServletException及其子类匹配。
定义零(0)个或多个异常类,这些异常类必须是Throwable的子类,指示哪些异常类型不能导致事务回滚。 这是构造回滚规则(与noRollbackForClassName相比)的首选方法,它匹配异常类及其子类。
一个布尔标志,如果事务实际上是只读的,则可以将其设置为true,从而允许在运行时进行相应的优化。 默认为false。 这只是作为实际事务子系统的提示;它不一定会导致写入访问尝试失败。无法解释只读提示的事务管理器在请求只读事务时不会引发异常,而是默默地忽略该提示。
此事务的超时时间(秒)。 默认为基础事务系统的默认超时。为Propagation.REQUIRED和Propagation.REQUIRES_NEW设计的参数,因为它只适用于新启动的事务。默认值为-1,表示不设置超时时间。
此事务的超时时间(秒)。 默认为基础事务系统的默认超时。 专门设计用于Propagation.REQUIRED和Propagation.REQUIRES_NEW,因为它只适用于新启动的事务。
事务隔离级别。 默认为Isolation.DEFAULT. 专门为Propagation.REQUIRED 和 Propagation.REQUIRES_NEW设计使用的,因为它只适用于新启动的事务。如果您希望隔离级别声明在参与具有不同隔离级别的现有事务时被拒绝,请考虑在事务管理器上切换“验证有效事务”标志为“true”。
事务传播类型。 默认为 Propagation.REQUIRED.
定义零(0)个或多个事务标签。标签可用于描述事务 ,并可由单个事务管理器进行评估。标签可能仅用于描述目的,或映射到预定义的事务管理器特定选项。 请参阅实际事务管理器实现的描述,了解它如何评估事务标签。
指定事务的限定符值。 可用于确定目标事务管理器,与特定TransactionManager bean定义的限定符值(或bean名称)匹配。
propagation的取值定义成了一个枚举类,如下所示:
REQUIRED 其值为0,支持当前事务,如果不存在,则创建新事务。类似于同名的EJB事务属性。这是事务注解的默认设置。
SUPPORTS 其值为1,支持当前事务,如果不存在,则以非事务方式执行。类似于同名的EJB事务属性。 注意:对于具有事务同步的事务管理器,SUPPORTS 与完全没有事务略有不同,因为它定义了同步将应用的事务范围。因此,相同的资源(JDBC连接、Hibernate会话等)将在整个指定范围内共享。请注意,这取决于事务管理器的实际同步配置。
MANDATORY 支持当前事务,如果不存在则抛出异常。类似于同名的EJB事务属性。
REQUIRES_NEW 创建新事务,并暂停当前事务(如果存在)。类似于同名的EJB事务属性。 注意:实际的事务暂停不会在所有交易管理器上立即生效。这尤其适用于JtaTransactionManager。JtaTransactionManager,它需要TransactionManager 可供其使用(在标准Java EE中是特定于服务器的)。
NOT_SUPPORTED 以非事务方式执行,如果当前事务存在,则暂停当前事务。类似于同名的EJB事务属性。 注意:实际的事务暂停不会在所有事务管理器上立即生效。这尤其适用于JtaTransactionManager。JtaTransactionManager,它需要TransactionManager可供其使用(在标准Java EE中是特定于服务器的)。
NEVER 以非事务方式执行,如果存在事务,则抛出异常。类似于同名的EJB事务属性。
NESTED 如果存在当前事务,则在嵌套事务中执行,否则按要求执行。EJB中没有类似的特性。 注意:嵌套事务的实际创建只适用于特定的事务管理器。开箱即用,这只适用于JDBC DataSourceTransactionManager。一些JTA提供者可能也支持嵌套事务。
枚举,用来表示Transactional 注解的事务隔离级别,与TransactionDefinition 接口定义的事务隔离级别相一致。 枚举定义如下:
DEFAULT 使用基础数据存储的默认隔离级别。所有其他级别都对应于JDBC隔离级别。
READ_UNCOMMITTED 一个常数,指示可能发生脏读、不可重复读和幻象读。此级别允许一个事务更改的行在提交该行的任何更改之前被另一个事务读取(“脏读”)。如果回滚了任何更改,则第二个事务将检索到无效行。
READ_COMMITTED 指示防止脏读的常数;可能会发生不可重复读取和幻象读取。此级别仅禁止事务读取包含未提交更改的行。
REPEATABLE_READ 指示防止脏读和不可重复读的常数;可能会发生幻象读取。该级别禁止事务读取包含未提交更改的行,还禁止一个事务读取一行,第二个事务更改该行,第一个事务重新读取该行,第二次获得不同的值(“不可重复读取”)。
SERIALIZABLE 一个常数,指示防止脏读、不可重复读和幻象读。该级别包括隔离可重复读取的禁止,并进一步禁止一个事务读取满足where条件的所有行,第二个事务插入满足where条件的行,第一个事务重新读取相同条件,在第二次读取中检索附加的“幻影”行。
事务注解@Transactional不起作用
? ? ? ?如果Transactional注解应用在非public修饰的方法上,Transactional将会失效。
? ? ? 1》在主方法上,不加@Transactional注解,在子方法上加@Transactional注解,主方法调用子方法,这种情况将会时效
? ? ? 2》在主方法上,加@Transactional注解,子方法上有事务操作,这时候是起作用的。
? ? ? 3》在类上加@Transactional注解,在方法上也加@Transactional注解,方法上的会覆盖类上面的。
? ? ?在业务方法中一般不需要catch异常,如果非要catch一定要抛出throw new RuntimeException(),或者注解中指定抛异常类型? @Transactional(rollbackFor=Exception.class),否则会导致事务失效,数据commit造成数据不一致,所以有些时候try catch反倒会画蛇添足。
? ? Spring默认抛出了未检查unchecked异常(继承自 RuntimeException 的异常)或者 Error才回滚事务;其他异常不会触发回滚事务。如果在事务中抛出其他类型的异常,但却期望 Spring 能够回滚事务,就需要指定?rollbackFor属性。
? ? ?配置错误导致的,这种情况一般不太会出现
? ? ?如果出现配置的下面的三种 propagation,事务将不会发生回滚。
? ? ransactionDefinition.PROPAGATION_SUPPORTS:如果当前存在事务,则加入该事务;如果当前没有事务,则以非事务的方式继续运行。
? ? TransactionDefinition.PROPAGATION_NOT_SUPPORTED:以非事务方式运行,如果当前存在事务,则把当前事务挂起。
? ? TransactionDefinition.PROPAGATION_NEVER:以非事务方式运行,如果当前存在事务,则抛出异常。
你了解的Spring 的 @Transactional 注解控制事务,失效场景知多少?
这里以 MySQL 为例,其 MyISAM 引擎是不支持事务操作的,InnoDB 才是支持事务的引擎,一般要支持事务都会使用 InnoDB。
根据 MySQL 的官方文档:
https://dev.mysql.com/doc/refman/5.5/en/storage-engine-setting.html
从 MySQL 5.5.5 开始的默认存储引擎是:InnoDB,之前默认的都是:MyISAM,所以这点要值得注意,底层引擎不支持事务再怎么搞都是无济于事。
如下代码所示,当前数据源若没有配置事务管理器,那也是白搭!
@Bean public PlatformTransactionManager transactionManager(DataSource dataSource) { return new DataSourceTransactionManager(dataSource); }
如果此时把 @Service 注解注释掉,这个类就不会被加载成一个 Bean,那这个类就不会被 Spring 管理了,事务自然就失效了。
以下引自spring官方文档:
大致意思是:
@Transactional 只能用于 public 的方法上,否则事务会失效。如果要用在非 public 方法上,可以开启 AspectJ 代理模式。
例1:
例1 中,update方法上面没有加 @Transactional 注解,调用有 @Transactional 注解的 updateOrder 方法,updateOrder 方法上的事务管用吗?
例2:
例2 中,update方法上面加了 @Transactional 注解,调用有 @Transactional 注解的 updateOrder 方法,updateOrder 方法上的事务管用吗?
很遗憾,这两个例子中, updateOrder 方法上的事务都不管用
因为它们发生了自身调用,就是调该类自己的方法,而没有经过 Spring 的代理类,默认只有在外部调用事务才会生效,这也是老生常谈的经典问题了。
6.1这个也是出现比较多的场景:把异常吃了,然后又不抛出来,事务也不会回滚!
6.2
这样事务也是不生效的,因为默认回滚的是:RuntimeException,如果你想触发其他异常的回滚,需要在注解上配置一下,如:
@Transactional(rollbackFor = Exception.class) 这个配置仅限于 Throwable 异常类及其子类。
Propagation.NOT_SUPPORTED:表示不以事务运行,当前若存在事务则挂起。这表示不支持以事务的方式运行,所以即使事务生效也是白搭!
分布式事务能用@transactional吗
1. 在需要事务管理的地方加@Transactional 注解。@Transactional 注解可以被应用于接口定义和接口方法、类定义和类的 public 方法上。
2. @Transactional 注解只能应用到 public 可见度的方法上。 如果你在 protected、private 或者 package-visible 的方法上使用 @Transactional 注解,它也不会报错, 但是这个被注解的方法将不会展示已配置的事务设置。
3. 注意仅仅 @Transactional 注解的出现不足于开启事务行为,它仅仅 是一种元数据。必须在配置文件中使用配置元素,才真正开启了事务行为。
4. 通过 元素的 "proxy-target-class" 属性值来控制是基于接口的还是基于类的代理被创建。如果 "proxy-target-class" 属值被设置为 "true",那么基于类的代理将起作用(这时需要CGLIB库cglib.jar在CLASSPATH中)。如果 "proxy-target-class" 属值被设置为 "false" 或者这个属性被省略,那么标准的JDK基于接口的代理将起作用。
标准的JDK基于接口的代理将起作用-->
proxy-target-class="false"/>
基于类的代理将起作用 ,同时 cglib.jar必须在CLASSPATH中
proxy-target-class="true"/>
-->
非JTA事务(即非分布式事务), 事务配置的时候 ,需要指定dataSource属性(非分布式事务,事务是在数据库创建的链接上开启。)-->
JTA事务(非分布式事务), 事务配置的时候 ,不能指定dataSource属性(分布式事务,是有全局事务来管理数据库链接的)-->
注解@Transactional cglib与java动态代理最大区别是代理目标对象不用实现接口,那么注解要是写到接口方法上,要是使用cglib代理,这是注解事物就失效了,为了保持兼容注解最好都写到实现类方法上。
5. Spring团队建议在具体的类(或类的方法)上使用 @Transactional 注解,而不要使用在类所要实现的任何接口上。在接口上使用 @Transactional 注解,只能当你设置了基于接口的代理时它才生效。因为注解是 不能继承 的,这就意味着如果正在使用基于类的代理时,那么事务的设置将不能被基于类的代理所识别,而且对象也将不会被事务代理所包装。
6. @Transactional 的事务开启 ,或者是基于接口的 或者是基于类的代理被创建。所以在同一个类中一个方法调用另一个方法有事务的方法,事务是不会起作用的。
public interface PersonService {
//删除指定id的person
public void delete(Integer personid) ;
//删除指定id的person,flag
public void delete(Integer personid,boolean flag) ;
}
public class PersonServiceBean implements PersonService {
private JdbcTemplate jdbcTemplate;
public void delete(Integer personid){
try{
this.delete(personid,true)
System.out.println("delete success");
}catch(Exception e){
System.out.println("delete failed");
}
}
@Transactional
//此时,事务根本就没有开启, 即数据库会默认提交该操作,即记录别删除掉 public void delete(Integer personid,boolean flag){
if(flag == ture){
jdbcTemplate.update("delete from person where id=?", new Object[]{personid},
new int[]{java.sql.Types.INTEGER});
throw new RuntimeException("运行期例外");
}
}
}
public class PersonServiceBeanTest{
PersonService ps = new PersonServiceBean ();
ps.delete(5);
}
7. Spring使用声明式事务处理,默认情况下,如果被注解的数据库操作方法中发生了unchecked异常,所有的数据库操作将rollback;如果发生的异常是checked异常,默认情况下数据库操作还是会提交的。
-----------------------------------------------------------------------------------------------------------------------------------------------
public interface PersonService {
//删除指定id的person
public void delete(Integer personid) ;
//获取person
public Person getPerson(Integer personid);
}
//PersonServiceBean 实现了PersonService 接口,则基于接口的还是基于类的代理 都可以实现事务
@Transactional public class PersonServiceBean implements PersonService {
private JdbcTemplate jdbcTemplate;
//发生了unchecked异常,事务回滚, @Transactional
public void delete(Integer personid){
jdbcTemplate.update("delete from person where id=?", new Object[]{personid},
new int[]{java.sql.Types.INTEGER});
throw new RuntimeException("运行期例外");
}
}
---------------------------------------------------------------------------------------------------------------------------------------------------
public interface PersonService {
//删除指定id的person
public void delete(Integer personid) throws Exception;
//获取person
public Person getPerson(Integer personid);
}
@Transactional
public class PersonServiceBean implements PersonService {
//发生了checked异常,事务不回滚,即数据库记录仍能被删除,
//checked的例外,需要我们在外部用try/catch语法对调用该方法的地方进行包含 @Transactional
public void delete(Integer personid) throws Exception{
jdbcTemplate.update("delete from person where id=?", new Object[]{personid},
new int[]{java.sql.Types.INTEGER});
throw new Exception("运行期例外");
}
}
---------------------------------------------------------------------------------------------------------------------------------------------------
但是,对于checked这种例外,默认情况下它是不会进行事务回滚的,但是如果我们需要它进行事务回滚,这时候可以在delete方法上通过@Transaction这个注解来修改它的行为。
@Transactional
public class PersonServiceBean implements PersonService {
@Transactional(rollbackFor=Exception.class)
//rollbackFor这属性指定了,既使你出现了checked这种例外,那么它也会对事务进行回滚
public void delete(Integer personid) throws Exception{
jdbcTemplate.update("delete from person where id=?", new Object[]{personid},
new int[]{java.sql.Types.INTEGER});
throw new Exception("运行期例外");
}
}
---------------------------------------------------------------------------------------------------------------------------------------------------
在PersonServiceBean这个业务bean里面,有一些事务是不需要事务管理的,好比说获取数据的getPersons方法,getPerson方法。因为@Transactional 放在了类的上面。
此时,可以采用propagation这个事务属性@Transactional(propagation=Propagation.NOT_SUPPORTED),propagation这个属性指定了事务传播行为,我们可以指定它不支持事务,当我们这么写了之后,Spring容器在getPersons方法执行前就不会开启事务.
@Transactional
public class PersonServiceBean implements PersonService {
@Transactional(propagation=Propagation.NOT_SUPPORTED)
//则此方法 就不会开启事务了
public Person getPerson(Integer personid)
{
}
}
SSH的Spring注解@Transactional什么作用?只能放在Dao层吗?请不要复制粘贴别人的答案
你好
1.方法加上这个注解之后,事务管理就交由Spring来处理。
2.也可以放在service层。
@Transactional采用注解式事务,所有标记为这个注解的并且能被spring扫描到的方法都会根据@Transactional的配置来使用事务,一般事务放在一个单元操作中,比如同时保存两个表,那么需要对这一个操作开启事务,要么都成功,一个失败的话事务回滚。也就是说不一定放在Dao层,
transactional注解是基于aop的吗
@Transactional采用注解式事务,所有标记为这个注解的并且能被spring扫描到的方法都会根据@Transactional的配置来使用事务,一般事务放在一个单元操作中,比如同时保存两个表,那么需要对这一个操作开启事务,要么都成功,一个失败的话事务回滚。也就是说不一定放在Dao层,
Spring Boot 项目中配置多数据源@Transactional注解失效问题
当一个Spring Boot 项目在配置了多个数据源 , 在编写 Service层方法 的时候 , 直接在service方法的上添加的 @Transactional 直接实现事务管理的方式是失效的 .
以最近接触到的一个持久层框架使用的是Jpa的项目为例 , 该项目通过硬编码(配置类)的方式 , 在项目中配置了两个不同的数据源 , 所以这个项目分别根据两个数据源配置了各自的事务管理器 PlatformTransactionManager , 如下 :
第一个数据源的事务管理器配置类 :
第二个数据源事务管理器配置类 :
可以看到第二个事务管理器的Bean方法上添加了 @Primary 注解 , 所以在通过 PlatformTransactionManager 类型注入事务管理器的bean时 , 默认是根据类型去注入 , 如果该类型有多个 Bean , 如不通过bean的名字去注入 , 则默认是会注入被 @Primary 标识的bean的 ;
所以在这个项目中 , 当在业务层方法添加 @Transactional 注解时 , 默认是调用了 transactionManagerTwo 这个bean , 而我在编写service层的方法时 , 调用的是第一个数据源对应的Dao层方法 , 所以直接添加 @Transactional 是不能实现事务管理的 ,
需要在使用 @Transactional 注解时指定使用的事务管理器的bean的名字 , 比如我这里调用的是第一个数据源的dao层方法 , 所以需要指定对应的事务管理器 : @Transactional(transactionManager = "transactionManagerOne") .
Spring 使用注解方式进行事务管理
使用步骤:
事务的传播行为和隔离级别
大家在使用spring的注解式事务管理时,对事务的传播行为和隔离级别可能有点不知所措,下边就详细的介绍下以备方便查阅。
事物注解方式: @Transactional
当标于类前时, 标示类中所有方法都进行事物处理 , 例子:
当类中某些方法不需要事物时:
事物超时设置: @Transactional(timeout=30) //默认是30秒
事务隔离级别: @Transactional(isolation = Isolation.READ_UNCOMMITTED) 读取未提交数据(会出现脏读, 不可重复读) 基本不使用 @Transactional(isolation = Isolation.READ_COMMITTED) 读取已提交数据(会出现不可重复读和幻读) @Transactional(isolation = Isolation.REPEATABLE_READ) 可重复读(会出现幻读) @Transactional(isolation = Isolation.SERIALIZABLE) 串行化
MYSQL: 默认为REPEATABLE_READ级别 SQLSERVER: 默认为READ_COMMITTED
脏读 : 一个事务读取到另一事务未提交的更新数据 不可重复读 : 在同一事务中, 多次读取同一数据返回的结果有所不同, 换句话说, 后续读取可以读到另一事务已提交的更新数据. 相反, "可重复读"在同一事务中多次 读取数据时, 能够保证所读数据一样, 也就是后续读取不能读到另一事务已提交的更新数据 幻读 : 一个事务读到另一个事务已提交的insert数据
@Transactional注解中常用参数说明
续表)
注意的几点: 1 @Transactional 只能被应用到public方法上, 对于其它非public的方法,如果标记了@Transactional也不会报错,但方法没有事务功能. 2用 spring 事务管理器,由spring来负责数据库的打开,提交,回滚.默认遇到运行期例外(throw new RuntimeException("注释");)会回滚,即遇到不受检查(unchecked)的例外时回滚;而遇到需要捕获的例外(throw new Exception("注释");)不会回滚,即遇到受检查的例外(就是非运行时抛出的异常,编译器会检查到的异常叫受检查例外或说受检查异常)时,需我们指定方式来让事务回滚 要想所有异常都回滚,要加上 @Transactional( rollbackFor={Exception.class,其它异常}) .如果让unchecked例外不回滚: @Transactional(notRollbackFor=RunTimeException.class) 如下: @Transactional(rollbackFor=Exception.class) //指定回滚,遇到异常Exception时回滚 public void methodName() { throw new Exception("注释"); } @Transactional(noRollbackFor=Exception.class)//指定不回滚,遇到运行期例外(throw new RuntimeException("注释");)会回滚 public ItimDaoImpl getItemDaoImpl() { throw new RuntimeException("注释"); }
3、@Transactional 注解应该只被应用到 public 可见度的方法上。 如果你在 protected、private 或者 package-visible 的方法上使用 @Transactional 注解,它也不会报错, 但是这个被注解的方法将不会展示已配置的事务设置。
4、@Transactional 注解可以被应用于接口定义和接口方法、类定义和类的 public 方法上。然而,请注意仅仅 @Transactional 注解的出现不足于开启事务行为,它仅仅 是一种元数据,能够被可以识别 @Transactional 注解和上述的配置适当的具有事务行为的beans所使用。上面的例子中,其实正是 元素的出现 开启 了事务行为。
5、Spring团队的建议是你在具体的类(或类的方法)上使用 @Transactional 注解,而不要使用在类所要实现的任何接口上。你当然可以在接口上使用 @Transactional 注解,但是这将只能当你设置了基于接口的代理时它才生效。因为注解是 不能继承 的,这就意味着如果你正在使用基于类的代理时,那么事务的设置将不能被基于类的代理所识别,而且对象也将不会被事务代理所包装(将被确认为严重的)。因 此,请接受Spring团队的建议并且在具体的类上使用 @Transactional 注解。
spring哪些注解会被代理
1、Transactional:用于声明事务的注解。当在Service层或DAO层方法上使用该注解时,Spring会自动为该方法生成一个动态代理对象,使其具有事务管理的功能。2、Cacheable、CachePut、CacheEvict:用于声明缓存的注解。当在Service层方法上使用这些注解时,Spring会自动为该方法生成一个动态代理对象,使其具有缓存管理的功能。3、Async:用于声明异步方法的注解。当在Service层方法上使用该注解时,Spring会自动为该方法生成一个动态代理对象,使其具有异步执行的功能。4、Scheduled:用于声明定时任务的注解。当在Service层方法上使用该注解时,Spring会自动为该方法生成一个动态代理对象,使其具有定时任务的功能。