spring的@Transactional注解详细用法

合集下载

Spring中的@Transactional（rollbackFor=Exception.。。。

Spring中的@Transactional（rollbackFor=Exception.。

当作⽤于类上时，该类的所有 public ⽅法将都具有该类型的事务属性，同时，我们也可以在⽅法级别使⽤该标注来覆盖类级别的定义。

在项⽬中，@Transactional(rollbackFor=Exception.class)，如果类加了这个注解，那么这个类⾥⾯的⽅法抛出异常，就会回滚，数据库⾥⾯的数据也会回滚。

在@Transactional注解中如果不配置rollbackFor属性,那么事物只会在遇到RuntimeException的时候才会回滚,加上rollbackFor=Exception.class,可以让事物在遇到⾮运⾏时异常时也回滚。

@Transactional注解的全部属性详解@Transactional属性属性类型描述value String可选的限定描述符，指定使⽤的事务管理器propagation enum: Propagation可选的事务传播⾏为设置isolation enum: Isolation可选的事务隔离级别设置readOnly boolean读写或只读事务，默认读写timeout int (in seconds granularity)事务超时时间设置rollbackFor Class对象数组，必须继承⾃Throwable导致事务回滚的异常类数组rollbackForClassName类名数组，必须继承⾃Throwable导致事务回滚的异常类名字数组noRollbackFor Class对象数组，必须继承⾃Throwable不会导致事务回滚的异常类数组noRollbackForClassName类名数组，必须继承⾃Throwable不会导致事务回滚的异常类名字数组。

dstransactional注解

dstransactional注解`@Transactional` 是 Spring 框架中的注解，用于将方法标记为事务性方法。

当在方法上添加 `@Transactional` 注解时，Spring 将会管理该方法的事务。

使用 `@Transactional` 注解时，需要注意以下几点：1. 事务的传播行为：可以通过 `propagation` 属性指定事务的传播行为，例如 `REQUIRED`、`REQUIRES_NEW` 等。

默认情况下，事务将会使用调用方法的事务，如果不存在，则会创建新的事务。

2. 事务的隔离级别：可以通过 `isolation` 属性指定事务的隔离级别，例如 `READ_COMMITTED`、`SERIALIZABLE` 等。

默认情况下，事务将会使用数据库的默认隔离级别。

3. 回滚规则：可以通过 `rollbackFor` 或 `noRollbackFor` 属性指定在遇到哪些异常时回滚事务。

默认情况下，事务会在遇到`RuntimeException` 或其子类异常时回滚。

4. 事务超时：可以通过 `timeout` 属性指定事务的超时时间，单位为秒。

如果方法执行时间超过了指定的超时时间，事务将会被回滚。

默认情况下，事务没有超时限制。

示例代码：```java@Transactionalpublic void saveUser(User user) {userRepository.save(user);}@Transactional(propagation = Propagation.REQUIRES_NEW, isolation = Isolation.READ_COMMITTED)public void updateUser(User user) {userRepository.update(user);}```在上述示例代码中，`saveUser` 方法标记为事务性方法，默认使用调用方法的事务。

transactional注解解析

transactional注解解析（原创版）目录1.介绍 transactional 注解2.transactional 注解的作用3.transactional 注解的使用方法4.transactional 注解的实例5.结论正文1.介绍 transactional 注解transactional 注解是 Spring 框架中的一种注解，主要用于实现事务的传播行为。

事务是数据库操作过程中的一种逻辑单元，它可以确保数据库操作的一致性和完整性。

在 Spring 中，通过 transactional 注解可以方便地配置事务的传播行为，提高代码的可读性和可维护性。

2.transactional 注解的作用transactional 注解主要有以下作用：（1）定义事务的传播行为。

事务的传播行为包括事务的传播范围、事务的隔离级别、事务的超时时间等。

transactional 注解可以方便地配置这些事务参数。

（2）支持事务的嵌套。

在一个事务中，可能会涉及到多个子事务。

通过 transactional 注解，可以实现事务的嵌套，确保子事务与父事务的一致性和完整性。

（3）简化事务管理。

transactional 注解可以简化事务管理，减少事务管理的代码量。

通过 transactional 注解，可以方便地实现事务的传播行为，而不需要手动编写事务管理代码。

3.transactional 注解的使用方法在 Spring 框架中，transactional 注解的使用方法如下：（1）在需要进行事务处理的方法或类上添加 transactional 注解。

例如，对于一个需要进行事务处理的方法，可以使用如下代码：```java@Transactionalpublic void someMethod() {// 事务处理代码}```（2）在 transactional 注解中，可以配置事务的传播行为、隔离级别等参数。

例如，可以配置事务的传播行为为 Propagation.REQUIRED，表示当前事务必须参与数据库操作：```java@Transactional(propagation = Propagation.REQUIRED)public void someMethod() {// 事务处理代码}```4.transactional 注解的实例以下是一个使用 transactional 注解的实例：```java@Servicepublic class UserService {@Autowiredprivate UserDao userDao;@Transactionalpublic void updateUser(Long id, String newName) {User user = userDao.findById(id);if (user!= null) {user.setName(newName);userDao.update(user);}}}```在这个实例中，updateUser 方法被添加了 transactional 注解，表示该方法需要进行事务处理。

@Transactional注解参数详解

@Transactional注解参数详解参数⼀: propagation详情如下:REQUIRED：⽀持当前事务，如果当前没有事务，就新建⼀个事务。

这是最常见的选择。

SUPPORTS：⽀持当前事务，如果当前没有事务，就以⾮事务⽅式执⾏。

MANDATORY：⽀持当前事务，如果当前没有事务，就抛出异常。

REQUIRES_NEW：新建事务，如果当前存在事务，把当前事务挂起。

NOT_SUPPORTED：以⾮事务⽅式执⾏操作，如果当前存在事务，就把当前事务挂起。

NEVER：以⾮事务⽅式执⾏，如果当前存在事务，则抛出异常。

NESTED：⽀持当前事务，如果当前事务存在，则执⾏⼀个嵌套事务，如果当前没有事务，就新建⼀个事务。

参数⼆:事物超时设置: timeout默认30秒参数三:事务隔离级别:isolation详情如下:Isolation.READ_UNCOMMITTED : 读取未提交数据(会出现脏读, 不可重复读) 基本不使⽤Isolation.READ_COMMITTED : 读取已提交数据(会出现不可重复读和幻读)Isolation.REPEATABLE_READ：可重复读(会出现幻读)Isolation.SERIALIZABLE：串⾏化备注:MYSQL: 默认为REPEATABLE_READ级别SQLSERVER: 默认为READ_COMMITTED参数四: readOnly属性⽤于设置当前事务是否为只读事务，设置为true表⽰只读，false则表⽰可读写，默认值为false。

参数五:rollbackFor该属性⽤于设置需要进⾏回滚的异常类数组，当⽅法中抛出指定异常数组中的异常时，则进⾏事务回滚。

例如：指定单⼀异常类：@Transactional(rollbackFor=RuntimeException.class)指定多个异常类：@Transactional(rollbackFor={RuntimeException.class, Exception.class})参数六: rollbackForClassName该属性⽤于设置需要进⾏回滚的异常类名称数组，当⽅法中抛出指定异常名称数组中的异常时，则进⾏事务回滚。

事务回滚的注解

事务回滚的注解在Java编程中，我们经常需要使用事务来确保一组相关的操作在执行过程中是不可分割的。

但有时候发生了不可预料的因素导致事务执行失败，如果不进行回滚操作则会对数据完整性造成影响。

因此，事务回滚成为了非常重要的一环。

为了简化回滚操作，我们可以使用一些注解来实现自动回滚。

下面是一些在Spring框架中常用的事务回滚的注解：1. @Transactional这个注解是在方法上使用的，将方法标记为一个事务处理方法。

如果在方法执行中发生异常，则方法内对数据库进行的操作会自动回滚到方法调用之前的状态。

2. @Transactional(propagation=Propagation.REQUIRES_NEW)这个注解也是在方法上使用的，它指定了一个新的事务，当被注解的方法被调用时，它将基于一个新的事务执行。

如果事务执行失败则进行回滚。

3. @Rollback这个注解可以用在测试代码中，用于指定测试方法执行后是否需要自动回滚。

例如：@Test@Rollback(true)public void testMethod() {// testing code here}4. @TransactionConfiguration这个注解可以在类级别使用，用于指定事务管理器和回滚操作。

例如：@TransactionConfiguration(transactionManager="transactionManager", defaultRollback=true)总之，在Java编程中，事务回滚是非常重要的，它可以确保数据的完整性和一致性。

而使用注解来实现自动回滚可以让我们的代码更加简单和可读，同时也减少了手动维护事务的复杂性。

Spring声明式事务@Transactional详解，事务隔离级别和传播行为

Spring声明式事务@Transactional详解，事务隔离级别和传播⾏为@Transactional注解⽀持9个属性的设置，这⾥只讲解其中使⽤较多的三个属性：readOnly、propagation、isolation。

其中propagation属性⽤来枚举事务的传播⾏为，isolation⽤来设置事务隔离级别，readOnly进⾏读写事务控制。

@Service@Transactional(readOnly = true)public class AppTradeRec2Service extends BaseService {@Autowiredprivate AppTradeRecDao appTradeRecDao;@Autowiredprivate ConsInfoDao consInfoDao;@Transactional(readOnly = false)public void payCharge(TradeRec tradeRec) {User usr = UserUtils.getUser();ConsInfo cons = consInfoDao.getByUser(usr.getId());//修改交易记录tradeRec.setPayBefore(cons.getAccountAmt());tradeRec.setPayAfter(cons.getAccountAmt() - tradeRec.getRcvAmt());tradeRec.setIsPay("99");appTradeRecDao.save(tradeRec);//修改账户余额cons.setAccountAmt(cons.getAccountAmt() - tradeRec.getRcvAmt());consInfoDao.save(cons);}}⼀、readOnly读写事务控制readOnly=true表明所注解的⽅法或类只是读取数据。

spring中事务注解@Transactional与trycatch的使用

spring中事务注解@Transactional与trycatch的使⽤spring事务注解@Transactional与trycatch在项⽬中 @service层中我们会经常在做⼀些增删改操作的⽅法上看到 spring 的事务注解 @transaction 已知@transaction 是让spring 帮我们实现事务的控制。

但是在项⽬中会经常看到有的⽅法中会存在trycatch块包括的⽅法上注解着@transactioneg：@Override@Transactionalpublic Json addOrder(TOrderAddReq tOrderAddReq) {try{//增删改⽅法} catch (Exception e) {.....e.printStackTrace();}// }return json;}上述的⽅法执⾏后可以看到事务并没有执⾏，接下来再看⼀个例⼦eg：@Override@Transactionalpublic Json addOrder(TOrderAddReq tOrderAddReq) {try{//增删改⽅法} catch (Exception e) {// ⼿动硬编码开启spring事务管理TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();e.printStackTrace();}// }return json;}上述⽅法执⾏后我们可以看到事务最后执⾏了，但实际上事务执⾏只是因为⼿动硬编码开启spring事务管理起了作⽤⽽⽅法上的注解并没有起作⽤接下来再看⼀个例⼦eg@Override@Transactionalpublic Json addOrder(TOrderAddReq tOrderAddReq) {try{//增删改⽅法} catch (Exception e) {throw new RuntimeException();}// }return json;}上述⽅法执⾏后我们可以看到事务是执⾏了的，但这⾥有个⼩细节:@Transactional不做任何配置默认是对抛出的unchecked 异常回滚，checked异常不会回滚，为了让所有异常都会让事务启动可以将 @Transactional配置为@Transactional(rollbackFor = Exception.class)解释：spring的事务边界是在调⽤业务⽅法之前开始的，业务⽅法执⾏完毕之后来执⾏commit or rollback(spring默认取决于是否抛出runtime异常).如果抛出runtime exception 并在你的业务⽅法中没有catch到的话，事务会回滚。

Spring中@Transactional用法详细介绍

Spring中@Transactional⽤法详细介绍Spring中@Transactional⽤法详细介绍引⾔：在spring中@Transactional提供⼀种控制事务管理的快捷⼿段，但是很多⼈都只是@Transactional简单使⽤，并未深⼊了解，其各个配置项的使⽤⽅法，本⽂将深⼊讲解各个配置项的使⽤。

1. @Transactional的定义Spring中的@Transactional基于动态代理的机制，提供了⼀种透明的事务管理机制，⽅便快捷解决在开发中碰到的问题。

在现实中，实际的问题往往⽐我们预期的要复杂很多，这就要求对@Transactional有深⼊的了解，以来应对复杂问题。

⾸先我们来看看@Transactional的代码定义：@Target({ElementType.METHOD, ElementType.TYPE})@Retention(RetentionPolicy.RUNTIME)@Inherited@Documentedpublic @interface Transactional {/*** A qualifier value for the specified transaction.* May be used to determine the target transaction manager,* matching the qualifier value (or the bean name) of a specific* {@link org.springframework.transaction.PlatformTransactionManager}* bean definition.*/String value() default "";/*** The transaction propagation type.* Defaults to {@link Propagation#REQUIRED}.* @see org.springframework.transaction.interceptor.TransactionAttribute#getPropagationBehavior()*/Propagation propagation() default Propagation.REQUIRED;/*** The transaction isolation level.* Defaults to {@link Isolation#DEFAULT}.* @see org.springframework.transaction.interceptor.TransactionAttribute#getIsolationLevel()*/Isolation isolation() default Isolation.DEFAULT;/*** The timeout for this transaction.* Defaults to the default timeout of the underlying transaction system.* @see org.springframework.transaction.interceptor.TransactionAttribute#getTimeout()*/int timeout() default TransactionDefinition.TIMEOUT_DEFAULT;/*** {@code true} if the transaction is read-only.* Defaults to {@code false}.* This just serves as a hint for the actual transaction subsystem;* it will not necessarily cause failure of write access attempts.* A transaction manager which cannot interpret the read-only hint will* not throw an exception when asked for a read-only transaction.* @see org.springframework.transaction.interceptor.TransactionAttribute#isReadOnly()*/boolean readOnly() default false;/*** Defines zero (0) or more exception {@link Class classes}, which must be a* subclass of {@link Throwable}, indicating which exception types must cause* a transaction rollback.* This is the preferred way to construct a rollback rule, matching the* exception class and subclasses.* Similar to {@link org.springframework.transaction.interceptor.RollbackRuleAttribute#RollbackRuleAttribute(Class clazz)}*/Class<? extends Throwable>[] rollbackFor() default {};/*** Defines zero (0) or more exception names (for exceptions which must be a* subclass of {@link Throwable}), indicating which exception types must cause* a transaction rollback.* This can be a substring, with no wildcard support at present.* A value of "ServletException" would match* {@link javax.servlet.ServletException} and subclasses, for example.* NB: Consider carefully how specific the pattern is, and whether* to include package information (which isn't mandatory). For example,* "Exception" will match nearly anything, and will probably hide other rules.* "ng.Exception" would be correct if "Exception" was meant to define* a rule for all checked exceptions. With more unusual {@link Exception}* names such as "BaseBusinessException" there is no need to use a FQN.* Similar to {@link org.springframework.transaction.interceptor.RollbackRuleAttribute#RollbackRuleAttribute(String exceptionName)}*/String[] rollbackForClassName() default {};/*** Defines zero (0) or more exception {@link Class Classes}, which must be a* subclass of {@link Throwable}, indicating which exception types must not* cause a transaction rollback.* This is the preferred way to construct a rollback rule, matching the* exception class and subclasses.* Similar to {@link org.springframework.transaction.interceptor.NoRollbackRuleAttribute#NoRollbackRuleAttribute(Class clazz)}*/Class<? extends Throwable>[] noRollbackFor() default {};/*** Defines zero (0) or more exception names (for exceptions which must be a* subclass of {@link Throwable}) indicating which exception types must not* cause a transaction rollback.* See the description of {@link #rollbackForClassName()} for more info on how* the specified names are treated.* Similar to {@link org.springframework.transaction.interceptor.NoRollbackRuleAttribute#NoRollbackRuleAttribute(String exceptionName)}*/String[] noRollbackForClassName() default {};}基于源代码，我们可以发现在@Transactional，原来有这么多的属性可以进⾏配置，从⽽达到复杂应⽤控制的⽬的。

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

spring的@Transactional注解详细用法各位读友大家好！你有你的木棉，我有我的文章，为了你的木棉，应读我的文章！若为比翼双飞鸟，定是人间有情人！若读此篇优秀文，必成天上比翼鸟！spring的@Transactional注解详细用法Spring Framework对事务管理提供了一致的抽象，其特点如下：为不同的事务API 提供一致的编程模型，比如JTA(Java Transaction API), JDBC, Hibernate, JPA(Java Persistence API和JDO(Java Data Objects)支持声明式事务管理，特别是基于注解的声明式事务管理，简单易用提供比其他事务API如JTA更简单的编程式事务管理API与spring数据访问抽象的完美集成事务管理方式spring支持编程式事务管理和声明式事务管理两种方式。

编程式事务管理使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。

对于编程式事务管理，spring推荐使用TransactionTemplate。

声明式事务管理建立在AOP之上的。

其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。

声明式事务最大的优点就是不需要通过编程的方式管理事务，这样就不需要在业务逻辑代码中掺杂事务管理的代码，只需在配置文件中做相关的事务规则声明(或通过基于@Transactional注解的方式)，便可以将事务规则应用到业务逻辑中。

显然声明式事务管理要优于编程式事务管理，这正是spring倡导的非侵入式的开发方式。

声明式事务管理使业务代码不受污染，一个普通的POJO对象，只要加上注解就可以获得完全的事务支持。

和编程式事务相比，声明式事务唯一不足地方是，后者的最细粒度只能作用到方法级别，无法做到像编程式事务那样可以作用到代码块级别。

但是即便有这样的需求，也存在很多变通的方法，比如，可以将需要进行事务管理的代码块独立为方法等等。

声明式事务管理也有两种常用的方式，一种是基于tx和aop 名字空间的xml配置文件，另一种就是基于@Transactional注解。

显然基于注解的方式更简单易用，更清爽。

自动提交(AutoCommit)与连接关闭时的是否自动提交自动提交默认情况下，数据库处于自动提交模式。

每一条语句处于一个单独的事务中，在这条语句执行完毕时，如果执行成功则隐式的提交事务，如果执行失败则隐式的回滚事务。

对于正常的事务管理，是一组相关的操作处于一个事务之中，因此必须关闭数据库的自动提交模式。

不过，这个我们不用担心，spring会将底层连接的自动提交特性设置为false。

org/springframework/jdbc/datasource/DataSourceTransactionManag er.java// switch to manual commit if necessary. this is very expensive in some jdbc drivers,// so we don't want to do it unnecessarily (for example if we've explicitly// configured the connection pool to set it already).if (con.getautocommit()) {txobject.setmustrestoreautocommit(true);if(logger.isd ebugenabled()) {logger.debug(“switching jdbc connection [“ + con + “] to manual commit”);}con.setautocommit(false);}有些数据连接池提供了关闭事务自动提交的设置，最好在设置连接池时就将其关闭。

但C3P0没有提供这一特性，只能依靠spring来设置。

因为JDBC规范规定，当连接对象建立时应该处于自动提交模式，这是跨DBMS的缺省值，如果需要,必须显式的关闭自动提交。

C3P0遵守这一规范，让客户代码来显式的设置需要的提交模式。

连接关闭时的是否自动提交当一个连接关闭时，如果有未提交的事务应该如何处理？JDBC规范没有提及，C3P0默认的策略是回滚任何未提交的事务。

这是一个正确的策略，但JDBC 驱动提供商之间对此问题并没有达成一致。

C3P0的autoCommitOnClose属性默认是false,没有十分必要不要动它。

或者可以显式的设置此属性为false，这样会更明确。

基于注解的声明式事务管理配置spring-servlet.xml还要在spring-servlet.xml中添加tx名字空间...xmln s:tx=“/schema/tx”xmlns:a op=“/schema/aop”xsi:schemaLocati on=“.../schema/txhttp://www.spring /schema/tx/spring-tx.xsd...MyBatis自动参与到spring事务管理中，无需额外配置，只要org.mybatis.spring.SqlSessionFactoryBean引用的数据源与DataSourceTransactionManager引用的数据源一致即可，否则事务管理会不起作用。

另外需要下载依赖包aopalliance.jar放置到WEB-INF/lib目录下。

否则spring初始化时会报异常ng.NoClassDefFoundError:org/aopalliance/intercept/MethodInterceptorspring事务特性spring 所有的事务管理策略类都继承自org.springframework.transaction.PlatformTransactionManager接口public interface PlatformTransactionManager {TransactionStatus getTransaction(TransactionDefinition definition)throws TransactionException;void commit(TransactionStatus status) throws TransactionException;void rollback(TransactionStatus status) throws TransactionException;}其中TransactionDefinition接口定义以下特性：事务隔离级别隔离级别是指若干个并发的事务之间的隔离程度。

TransactionDefinition 接口中定义了五个表示隔离级别的常量：TransactionDefinition.ISOLATION_DEFAULT：这是默认值，表示使用底层数据库的默认隔离级别。

对大部分数据库而言，通常这值就是TransactionDefinition.ISOLATION_READ_COMMITTED。

TransactionDefinition.ISOLATION_READ_UNCOMMITTED：该隔离级别表示一个事务可以读取另一个事务修改但还没有提交的数据。

该级别不能防止脏读，不可重复读和幻读，因此很少使用该隔离级别。

比如PostgreSQL实际上并没有此级别。

TransactionDefinition.ISOLATION_READ_COMMITTED：该隔离级别表示一个事务只能读取另一个事务已经提交的数据。

该级别可以防止脏读，这也是大多数情况下的推荐值。

TransactionDefinition.ISOLATION_REPEATABLE_READ：该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询，并且每次返回的记录都相同。

该级别可以防止脏读和不可重复读。

TransactionDefinition.ISOLATION_SERIALIZABLE：所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。

但是这将严重影响程序的性能。

通常情况下也不会用到该级别。

事务传播行为所谓事务的传播行为是指，如果在开始当前事务之前，一个事务上下文已经存在，此时有若干选项可以指定一个事务性方法的执行行为。

在TransactionDefinition定义中包括了如下几个表示传播行为的常量：TransactionDefinition.PROPAGATION_REQUIRED：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。

这是默认值。

TransactionDefinition.PROPAGATION_REQUIRES_NEW：创建一个新的事务，如果当前存在事务，则把当前事务挂起。

TransactionDefinition.PROPAGATION_SUPPORTS：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。

TransactionDefinition.PROPAGATION_NOT_SUPPORTED：以非事务方式运行，如果当前存在事务，则把当前事务挂起。

TransactionDefinition.PROPAGATION_NEVER：以非事务方式运行，如果当前存在事务，则抛出异常。

TransactionDefinition.PROPAGATION_MANDATORY：如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。

TransactionDefinition.PROPAGATION_NESTED：如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行；如果当前没有事务，则该取值等价于TransactionDefinition.PROPAGATION_REQUIRED。

事务超时所谓事务超时，就是指一个事务所允许执行的最长时间，如果超过该时间限制但事务还没有完成，则自动回滚事务。

在TransactionDefinition 中以int 的值来表示超时时间，其单位是秒。

默认设置为底层事务系统的超时值，如果底层数据库事务系统没有设置超时值，那么就是none，没有超时限制。

事务只读属性只读事务用于客户代码只读但不修改数据的情形，只读事务用于特定情景下的优化，比如使用Hibernate的时候，默认为读写事务。

spring事务回滚规则指示spring事务管理器回滚一个事务的推荐方法是在当前事务的上下文内抛出异常。