spring的@Transactional注解详细用法

合集下载

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

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注解

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注解解析

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注解参数详解

@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详解,事务隔离级别和传播行为

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的使⽤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⽤法详细介绍引⾔:在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.* <p>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}.* <p>This just serves as a hint for the actual transaction subsystem;* it will <i>not necessarily</i> cause failure of write access attempts.* A transaction manager which cannot interpret the read-only hint will* <i>not</i> 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.* <p>This is the preferred way to construct a rollback rule, matching the* exception class and subclasses.* <p>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.* <p>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.* <p><b>NB: </b>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.* <p>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 <b>not</b>* cause a transaction rollback.* <p>This is the preferred way to construct a rollback rule, matching the* exception class and subclasses.* <p>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 <b>not</b>* cause a transaction rollback.* <p>See the description of {@link #rollbackForClassName()} for more info on how* the specified names are treated.* <p>Similar to {@link org.springframework.transaction.interceptor.NoRollbackRuleAttribute#NoRollbackRuleAttribute(String exceptionName)}*/String[] noRollbackForClassName() default {};}基于源代码,我们可以发现在@Transactional,原来有这么多的属性可以进⾏配置,从⽽达到复杂应⽤控制的⽬的。

@Transactional注解详细用法

@Transactional注解详细用法

@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对象,只要加上注解就可以获得完全的事务⽀持。

和编程式事务相⽐,声明式事务唯⼀不⾜地⽅是,后者的最细粒度只能作⽤到⽅法级别,⽆法做到像编程式事务那样可以作⽤到代码块级别。

但是即便有这样的需求,也存在很多变通的⽅法,⽐如,可以将需要进⾏事务管理的代码块独⽴为⽅法等等。

用AspectJ方式来处理Spring的@Transactional注解式事务

用AspectJ方式来处理Spring的@Transactional注解式事务

⽤AspectJ⽅式来处理Spring的@Transactional注解式事务为节省你的时间,如果你你不清楚什么是Spring 、AspectJ、事务处理,本⽂就不适合你看。

你可以路过就⾛。

在⽹络应⽤中,我们⼏乎总是需要严密控制我们spring应⽤中的数据库事务的启动和结束。

为做到这⼀点,我们或多或少都已经通过AOP来做这些事情。

但⼀般都是在XXService、或XXController中封装处理请求的⽅法。

Spring有内置注解⽀持,因⽽你可以简单地通过@Transactional注解你的⽅法或类,并在配置⽂件中添加<tx:annotation-driven />,把相应⽅法封装于⼀个事务之中。

这听起来好像很简单。

但是,所有这些都是通过Spring 的代理对象封装并环绕增强原来的被注解@Transactional的类来实现的,但这种做法只有当事务⽅法是public的、并且是被代理类外部调⽤的情况下才会正常⼯作(可以参看Spring 事务处理模型图就明⽩,否则代理对象⾃⼰调⽤⾃⼰就会绕过对它的环绕事务增强,其他切⾯增强也是⼀样)。

这就很不爽了,意味着你不能在XXService或XXController内部串联处理⼀些具各⾃独⽴的事务,例如在XXController调⽤handleRequestInternal。

解决的办法是使⽤全功能完整成熟的AspectJ织⼊。

AspectJ织⼊⽅式同样⽀持@Transactional (其他⾃定义注解也⾏^_^),同时能被织⼊到所有⽅法中(不只是public),并且在内不外部都可以。

AspectJ有三种⽅式织⼊事务代码a.编译时(CTW). 拥有所有需要的源代码b.运⾏时(LTW).c.字节码织⼊(BTW).没有织⼊⽬标的源代码(如只有jar)这⾥我们使⽤CTW的⽅式Xml代码1. <beans xmlns="/schema/beans" xmlns:aop="/schema/aop">2.3. <aop:spring-configured>4.5. <bean id="annotationTransactionAspect" factory-method="aspectOf" class="org.springframework.transaction.aspectj.AnnotationTransactionAspect">6. <property name="transactionManager" ref="transactionManager"></property>7. </bean>8.9. <!-- the rest of your application here -->10. </beans>上⾯就是所有让Spring 使⽤Aspectj ⽅式@Transactional 注解事务的所有配置了。

transactional注解方法嵌套方法

transactional注解方法嵌套方法

transactional注解方法嵌套方法在编写Java应用程序时,我们经常会遇到需要在一个事务中执行多个方法的情况。

为了简化事务管理的过程,Spring框架提供了@Transactional注解。

这个注解可以应用在方法或类级别上,用于指示方法需要在一个事务中运行。

使用@Transactional注解的方法可以嵌套其他@Transactional注解的方法。

这种机制允许在一个事务中运行的方法中调用其他事务方法,确保了所有的操作都在同一个事务中进行。

在嵌套@Transactional注解的方法中,如果外部方法执行失败,则内部方法也会随之回滚。

当内部方法执行失败时,外部方法也会回滚。

这种嵌套事务的机制确保了所有方法的数据一致性和完整性。

当我们需要在一个事务中执行一系列数据库操作时,可以使用@Transactional注解的方法嵌套方法的方式。

例如,假设我们有一个方法A,它需要在一个事务中执行一系列数据库操作。

我们可以将这些数据库操作封装在一个方法B中,并在方法A中调用方法B。

通过使用@Transactional注解,方法A和方法B都将在同一个事务中执行,保证了数据的一致性。

需要注意的是,事务方法的嵌套并不是一种优选的方式,因为它可能导致性能上的问题。

每一次嵌套方法的调用都会导致事务的开启和关闭,这会带来额外的开销。

因此,在设计应用程序时,我们应该尽量避免过多的事务方法嵌套。

总结来说,@Transactional注解的方法嵌套方法可以在一个事务中执行多个方法,保证了数据的一致性和完整性。

但是需要注意嵌套方法会增加事务管理的开销,因此在设计应用程序时应慎重使用。

transaction注解用法

transaction注解用法

transaction注解用法“@Transactional”注解在Java开发中非常重要,特别是在处理数据库事务时。

一、基本用法1. 在方法级别使用。

假设我们有一个简单的Java类,这个类负责处理用户账户的存款操作。

- 在Spring框架下,你可以像这样使用“@Transactional”注解。

例如:- “```javaimportorg.springframework.transaction.annotation.Transactional;@Servicepublic class AccountService {@Autowiredprivate AccountRepository accountRepository;@Transactionalpublic void deposit(String accountNumber, double amount) {Account account =accountRepository.findByAccountNumber(accountNumber);account.setBalance(account.getBalance() + amount);accountRepository.save(account);}}```”- 这里的“@Transactional”注解告诉Spring框架,这个“deposit”方法应该在一个事务中运行。

如果在方法执行过程中出现任何异常,事务将会回滚,就像一个保护罩一样。

这就好比你在玩一个搭积木的游戏,每一步操作都很关键,如果中间有一步搭错了(出现异常),你可以选择把之前搭的部分都还原(事务回滚)。

2. 在类级别使用。

- 当你想让一个类中的多个方法都在事务环境下运行时,可以在类级别使用“@Transactional”注解。

- 例如:- “```java@Service@Transactionalpublic class OrderService {@Autowiredprivate OrderRepository orderRepository;public void createOrder(Order order) {orderRepository.save(order);}public void updateOrder(Order order) {orderRepository.save(order);}}```”- 在这个“OrderService”类中,“createOrder”和“updateOrder”方法都会在事务中执行。

transactional注解用法

transactional注解用法

一、transactional注解的概述transactional注解是Spring框架中用于管理事务的重要注解之一。

在实际项目开发中,事务管理是非常重要的,它可以确保数据操作的一致性和完整性。

使用transactional注解可以简化事务管理的代码编写,并且能够提高开发效率。

二、transactional注解的基本用法使用transactional注解非常简单,只需要在需要开启事务管理的方法上添加注解即可。

在Spring容器中,我们可以通过配置扫描包来使得Spring容器能够扫描到带有Transactional注解的方法,从而实现事务的开启和管理。

三、transactional注解的属性介绍1. propagation属性事务的传播行为是决定多个事务方法相互调用时事务如何传播的。

在transactional注解中,propagation属性用于设置事务的传播行为。

常用的传播行为包括:REQUIRED(如果当前没有事务,就新建一个事务;如果有事务则加入到当前事务);REQUIRES_NEW(每次都新建一个事务);SUPPORTS(如果当前没有事务,就以非事务方式执行;如果有,就用当前事务)等。

2. isolation属性事务的隔离级别是指多个事务之间的相互影响程度。

在transactional 注解中,isolation属性用于设置事务的隔禅级别。

常用的隔离级别包括:READ_UNCOMMITTED(可以读取未提交的数据);READ_COMMITTED(一个事务只能读取已提交的数据);REPEATABLE_READ(可重复读,确保一个事务不会读到另一个并发事务被更新的数据);SERIALIZABLE(最高的隔离级别,确保一个事务不会读到另一个并发事务中的未提交的数据)。

3. readOnly属性readOnly属性用于设置事务的只读属性,如果将readOnly设置为true,表示该事务是只读的,不会对数据进行修改操作。

SpringBoot事务注解@Transactional

SpringBoot事务注解@Transactional

SpringBoot事务注解@TransactionalSpringBoot提供了⾮常⽅便的事务操作,通过注解就可以实现事务的回滚,⾮常⽅便快捷,下⾯我们就说⼀下如何进⾏事务操作。

1. 事务说明在Spring中,事务有两种实现⽅式,分别是编程式事务管理和声明式事务管理两种⽅式。

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

对于编程式事务管理,spring推荐使⽤TransactionTemplate。

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

其本质是对⽅法前后进⾏拦截,然后在⽬标⽅法开始之前创建或者加⼊⼀个事务,在执⾏完⽬标⽅法之后根据执⾏情况提交或者回滚事务。

声明式事务管理不需要⼊侵代码,通过@Transactional就可以进⾏事务操作,更快捷⽽且简单。

推荐使⽤2. 如何使⽤在Mybatis中使⽤事务,⾮常简单,只需要在函数增加注解@Transactional,⽆需任何配置。

我们通过在controller层增加事务例⼦看下:@AutowiredOrderServiceorderService; //order操作的Service层@ApiOperation(value = "增加OrderCustomer")@RequestMapping(value = "", method = RequestMethod.POST)@ResponseBody@Transactionalpublic JsonBean<Order> insertOrder(@RequestParam(value = "order") String order) {try {//创建订单Order order = orderService.insert(user.getId(),is_company,fk_want_company_id);return new JsonBean(SUCCESS, orderCustomer);}catch (ErrorCodeException e){TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();return new JsonBean(e.getErrorCode());}}@Transactional可以作⽤于接⼝、接⼝⽅法、类以及类⽅法上。

spring事务注解@Transactional的实现原理(转)

spring事务注解@Transactional的实现原理(转)

spring事务注解@Transactional的实现原理(转)出处:Transactional是spring中定义的事务注解,在⽅法或类上加该注解开启事务。

主要是通过反射获取bean的注解信息,利⽤AOP对编程式事务进⾏封装实现。

AOP对事务的封装可以看。

我们先写个demo,感受它的加载过程。

spring事务注解:1. ⾃定义⼀个注解/*** @Target 作⽤域(作⽤在⽅法上,类上,或是属性上)* @Retention 运⾏周期* @interface 定义注解*/@Target(value = ElementType.METHOD)@Retention(RetentionPolicy.RUNTIME)public @interface MyAnnotation {//⾃定义注解的属性int id() default 0;String name() default "默认名称";String[]arrays();String title() default "默认标题";}2. 测试import ng.reflect.Method;public class User {@MyAnnotation(name="吴磊",arrays = {"2","3"})public void aMethod () {}public void bMethod () {}public static void main(String[] args) throws ClassNotFoundException {//1. 反射获取到类信息Class<?> forName = Class.forName("er");//2. 获取到当前类(不包含继承)所有的⽅法Method[] declaredMethods = forName.getDeclaredMethods();//3. 遍历每个⽅法的信息for (Method method : declaredMethods) {System.out.println("⽅法名称:" + method.getName());//4. 获取⽅法上⾯的注解MyAnnotation annotation = method.getDeclaredAnnotation(MyAnnotation.class);if(annotation == null) {System.out.println("该⽅法上没有加注解....");}else {System.out.println("Id:" + annotation.id());System.out.println("Name:" + ());System.out.println("Arrays:" + annotation.arrays());System.out.println("Title:" + annotation.title());}System.out.println("--------------------------");}}}=============================【控制台输出】⽅法名称:main该⽅法上没有加注解....--------------------------⽅法名称:aMethodId:0Name:吴磊Arrays:[ng.String;@74a14482Title:默认标题--------------------------⽅法名称:bMethod该⽅法上没有加注解....--------------------------总结:通过上⾯这么⼀个⼩demo我们就能发现,反射获取到每⼀个⽅法的注解信息然后进⾏判断,如果这是@Transactional注解,spring就会开启事务。

spring事务注解

spring事务注解

spring事务注解@Transactional只能被应用到public方法上, 对于其它非public的方法,如果标记了@Transactional也不会报错,但方法没有事务功能.Spring使用声明式事务处理,默认情况下,如果被注解的数据库操作方法中发生了unchecked异常,所有的数据库操作将rollback;如果发生的异常是checked 异常,默认情况下数据库操作还是会提交的。

这种默认的行为是可以改变的。

使用@Transactional注解的noRollbackFor和rollbackFor属性如:@Transactional(rollbackFor=Exception.class)可以使checked异常发生时,数据库操作也rollback、@Transactional(noRollbackFor=RuntimeException.class)可以使unchecked异常发生时也提交数据库操作。

也可以使用noRollbackForClassName、rollbackForClassName属性来指定一个异常类名的String数组来改变默认的行为。

读取数据库中的数据时是不需要事务管理的,这种情况下可以使用事务的传播行为来告诉Spring不需要开启事务,如:@Transactional(propagation = Propagation.NOT_SUPPORTED)。

事务的传播行为有:1. REQUIRED:表示业务方法需要在一个事务中处理,如果业务方法执行时已经在一个事务中,则加入该事务,否则重新开启一个事务。

这也是默认的事务传播行为;2. NOT_SUPPORTED:声明业务方法不需要事务,如果业务方法执行时已经在一个事务中,则事务被挂起,等方法执行完毕后,事务恢复进行;3. REQUIRES_NEW:表明业务方法需要在一个单独的事务中进行,如果业务方法进行时已经在一个事务中,则这个事务被挂起,并重新开启一个事务来执行这个业务方法,业务方法执行完毕后,原来的事务恢复进行;4. MANDATORY:该属性指定业务方法只能在一个已经存在的事务中进行,业务方法不能发起自己的事务;如果业务方法没有在一个既有的事务中进行,容器将抛出异常;5. SUPPORTS:该属性指定,如果业务方法在一个既有的事务中进行,则加入该事务;否则,业务方法将在一个没有事务的环境下进行;6. NEVER:指定业务方法不可以在事务中进行,如果业务方法执行时已经在一个事务中,容器将抛出异常;7. NESTED:该属性指定,如果业务方法在一个既有的事务中执行,则该业务方法将在一个嵌套的事务中进行;否则,按照REQUEIRED来对待。

@Transactional使用

@Transactional使用

@Transactional使⽤在SpringBoot项⽬中,我们经常会使⽤@Transactional注解进⾏声明式事务控制,就简单介绍⼀下@Transactional的使⽤。

要在Spring boot中⽀持事务,⾸先要导⼊Spring boot提供的JDBC或JPA依赖<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-jdbc</artifactId><scope>test</scope></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-jpa</artifactId><scope>test</scope></dependency>由于SpringBoot项⽬会⾃动开启事务⽀持,所以启动类上的@EnableTransactionManagement注解可以省略。

@Transactional不仅可以注解在⽅法上,也可以注解在类上。

当注解在类上的时候意味着此类的所有public⽅法都是开启事务的。

如果类级别和⽅法级别同时使⽤了@Transactional注解,则使⽤在类级别的注解会重载⽅法级别的注解。

使⽤@Transactional注解进⾏事务控制时,可以在其中添加有关“隔离级别”和“传播⾏为”的指定:(1)隔离级别DEFAULT :这是默认值,表⽰使⽤底层数据库的默认隔离级别。

对⼤部分数据库⽽⾔,通常这值就是: READ_COMMITTED 。

@Transactional锁表吗?关于Spring注解@Transactional和SQ。。。

@Transactional锁表吗?关于Spring注解@Transactional和SQ。。。

@Transactional锁表吗?关于Spring注解@Transactional和
SQ。

@Transactional 锁表吗?关于Spring注解@Transactional和SQL for update 的⼀些理解
⼯作前⼏年中,⼀直接触的是JDBC原⽣的事务处理⽅式。

1. 获取 connection
2. try {
con = getDBConnection();
// sql for update 锁A表, B表。

表记录
//增删改查
多个业务处理,
mit()
//最后提交
3. } catch Exception {
con. 回滚
}
4. finally {
con.close();
}
后期⽤了spring 后, @Transactional 实际上代替了try catch finally . 还有 con获取,提交,回滚的操作。

但是锁表记录的动作,并不在这个注解的职责⾥。

所以,在处理关键事务时,还是得在 dao层更新记录前,查询记录加⾏级锁的。

俗称悲观锁,或者不加锁使⽤version判断。

俗称乐观锁。

来搞⼀下的。

这两个是不同的职责范围,即:@Transactional注解不包含for update.。

如此。

⽽已。

spring注解-@Transactional事务几点注意

spring注解-@Transactional事务几点注意

spring注解-@Transactional事务⼏点注意这⾥⾯有⼏点需要⼤家留意:A. ⼀个功能是否要事务,必须纳⼊设计、编码考虑。

不能仅仅完成了基本功能就ok。

B. 如果加了事务,必须做好开发环境测试(测试环境也尽量触发异常、测试回滚),确保事务⽣效。

C. 以下列了事务使⽤过程的注意事项,请⼤家留意。

1. 不要在接⼝上声明@Transactional ,⽽要在具体类的⽅法上使⽤ @Transactional 注解,否则注解可能⽆效。

2.不要图省事,将@Transactional放置在类级的声明中,放在类声明,会使得所有⽅法都有事务。

故@Transactional应该放在⽅法级别,不需要使⽤事务的⽅法,就不要放置事务,⽐如查询⽅法。

否则对性能是有影响的。

3.使⽤了@Transactional的⽅法,对同⼀个类⾥⾯的⽅法调⽤, @Transactional⽆效。

⽐如有⼀个类Test,它的⼀个⽅法A,A再调⽤Test 本类的⽅法B(不管B是否public还是private),但A没有声明注解事务,⽽B有。

则外部调⽤A之后,B的事务是不会起作⽤的。

(经常在这⾥出错)4.使⽤了@Transactional的⽅法,只能是public,@Transactional注解的⽅法都是被外部其他类调⽤才有效,故只能是public。

道理和上⾯的有关联。

故在 protected、private 或者 package-visible 的⽅法上使⽤ @Transactional 注解,它也不会报错,但事务⽆效。

5.经过在ICORE-CLAIM中测试,效果如下:A.抛出受查异常XXXException,事务会回滚。

B.抛出运⾏时异常NullPointerException,事务会回滚。

C.Quartz中,execute直接调⽤加了@Transactional⽅法,可以回滚;间接调⽤,不会回滚。

(即上⽂3点提到的)D.异步任务中,execute直接调⽤加了@Transactional⽅法,可以回滚;间接调⽤,不会回滚。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 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&#39;t want to do it unnecessarily (for example if we&#39;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事务管理器回滚一个事务的推荐方法是在当前事务的上下文内抛出异常。

相关文档
最新文档