问题 正常情况下,我们都是在controller里调用service里的方法,这个方法如果需要加事务,就在方法上加上@Transactional,这样是没问题的,事务会生效. 可是如果像下面这样,绕以下,service里方法调用了自己类的方法,这个时候即使加了@Transactional,事务也不会生效. @Controller public class TestController { @Autowired private TestService testService; @GetMappin

对于像我这种喜欢滥用AOP的程序员,遇到坑也是习惯了,不仅仅是事务,其实只要脱离了Spring容器管理的所有对象,对于SpringAOP的注解都会失效,因为他们不是Spring容器的代理类,SpringAOP,就切入不了 当然可以使用原生ASPECTJ,不用SpringAOP,但是基于生态链问题,还是尽量使用SpringAOP 这里简单说一下,Spring如何选择使用CGLIB,或者是JDK代理, Spring 代理对象,cglib,jdk的问题思考,AOP 配置注解拦截 的一些问题.为什么不要

问题: 如果同一个类中有方法:methodA(); methodB().methodA()没有开启事务,methodB()开启了事务 且methodA()会调用methodB(). 那么,methodA()调用methodB()时,不会开启事务!!! 即:同一个类中,无事务的方法调用有事务的方法,结果就是没有事务!!! 原因:点这里 解决办法:要么声明要事务,要么分开成两个类,要么直接在方法里使用编程式事务. 建议直接分成两个类.

一.事务概述 1.1 什么是事务 事务是一组原子性的SQL查询,或者说是一个独立的工作单元.要么全部执行,要么全部不执行. 1.2 事务的特性(ACID) ①原子性(atomicity) 一个事务必须被视为一个不可分割的最小工作单元,整个事务中的所有操作要么全部提交成功,要么全部回滚,对于一个事务来说,不可能只执行其中的一部分操作 ②一致性(consistency) 数据库总是从一个一致性的状态转换到另外一个一致性的状态. ③隔离性(isolation) 一个事务所做的修改在最终提交以前,对其他

Spring事务传播机制回顾 Spring事务一个被讹传很广说法是:一个事务方法不应该调用另一个事务方法,否则将产生两个事务.结果造成开发人员在设计事务方法时束手束脚,生怕一不小心就踩到地雷. 其实这是不认识Spring事务传播机制而造成的误解,Spring对事务控制的支持统一在TransactionDefinition类中描述,该类有以下几个重要的接口方法: int getPropagationBehavior():事务的传播行为 int getIsolationLevel():事务的隔离级别

ServiceA.java文件: 查看Spring Tx的相关日志:  可以看到只创建了一个事物ServiceA.service方法的事务,但是callSelf方法却没有被事务增强; 分析原因:Spring事务生成的对象也是被Cglib或JDK代理的对象,就区别于该对象本身了, 代理的对象执行方法之前会走拦截器链,就不能同this方法. 解决方案: 使用Autowired注解将自身注入,然后调用注入属性的方法; 验证输出结果:  确实初始化了callSelf的事务; 2.之前Aop可以将代理对象

问题: 在Spring管理的项目中,方法A使用了Transactional注解,试图实现事务性.但当同一个class中的方法B调用方法A时,会发现方法A中的异常不再导致回滚,也即事务失效了. 当这个方法被同一个类调用的时候,spring无法将这个方法加到事务管理中. 我们来看一下生效时候和不生效时候调用堆栈日志的对比.     通过对比两个调用堆栈可以看出,spring的@Transactional事务生效的一个前提是进行方法调用前经过拦截器TransactionInterceptor,也就是说

一.JDBC编程特点 静态代码+动态变量=JDBC编程. 静态代码:比如所有的数据库连接池 都实现了DataSource接口,都实现了Connection接口. 动态变量:用户名.密码.连接的数据库.表名.SQL语句等信息. 在spring中动态变量能够通过注入的形式给予.这样的变成方式适合包装成模板.静态代码构成了模板,而动态变量是需要传入的参数. 二.核心类JdbcTemplate 1.基于模板的设置. 2.完成了资源的创建和释放的工作. 3.简化了我们的JDBC操作. 4.完成了对JDBC

上文见<spring事务管理器设计思想(一)> 对于第二个问题,涉及到事务的传播级别,定义如下: PROPAGATION_REQUIRED-- 如果当前没有事务,就新建一个事务.这是最常见的选择.  PROPAGATION_SUPPORTS-- 如果当前没有事务,就以非事务方式执行.  PROPAGATION_MANDATORY-- 如果当前没有事务,就抛出异常.  PROPAGATION_REQUIRES_NEW--新建事务,如果当前存在事务,把当前事务挂起.  PROPAGATION_NO

在最近做的一个项目里面,涉及到多数据源的操作,比较特殊的是,这多个数据库的表结构完全相同,由于我们使用的ibatis框架作为持久化层,为了防止每一个数据源都配置一套规则,所以重新实现了数据源,根据线程变量中指定的数据库连接名称来获取实际的数据源. 一个简单的实现如下: public class ProxyDataSource implements DataSource { /** 数据源池配置 */ private Map<String, DataSource> dataSourcePoolC

Spring 对事务控制的支持统一在 TransactionDefinition 类中描述,该类有以下几个重要的接口方法: int getPropagationBehavior():事务的传播行为 int getIsolationLevel():事务的隔离级别 int getTimeout():事务的过期时间 boolean isReadOnly():事务的读写特性. DefaultTransactionDefinition可以看到默认配置, private int propagationBeh

Spring声明式事务让我们从复杂的事务处理中得到解脱.使得我们再也无需要去处理获得连接.关闭连接.事务提交和回滚等这些操作.再也无需要我们在与事务相关的方法中处理大量的try-catch-finally代码. 我们在使用Spring声明式事务时,有一个非常重要的概念就是事务属性.事务属性通常由事务的传播行为,事务的隔离级别,事务的超时值和事务只读标志组成.我们在进行事务划分时,需要进行事务定义,也就是配置事务的属性. Spring在TransactionDefinition接口中定义这些属性,

配置spring事务管理的几种方式(声明式事务) 概要: Spring对编程式事务的支持与EJB有很大的区别.不像EJB和Java事务API(Java Transaction API, JTA)耦合在一起那样,Spring通过回调机制将实际的事务实现从事务性的代码中抽象出来.实际上,Spring对事务的支持甚至不需要JTA的实现.如果你的应用程序只使用一种持久化资源,Spring可以使用持久化本事所提供的事务性支持,这包括了JDBC,Hibernate以及Java持久化API(Java Pers

Spring抽象的DAO体系兼容多种数据访问技术,它们各有特色,各有千秋.像Hibernate是非常优秀的ORM实现方案,但对底层SQL的控制不太方便:而iBatis则通过模板化技术让你方便地控制SQL,但没有Hibernate那样高的开发效率:自由度最高的当然是直接使用Spring JDBC了,但它也是底层的,灵活的代价是代码的繁复.很难说哪种数据访问技术是最优秀的,只有在某种特定的场景下才能给出答案.所以在一个应用中,往往采用多个数据访问技术:一般是两种,一种采用ORM技术框架,而另一种采用

spring提供的事务管理可以分为两类:编程式的和声明式的.编程式的,比较灵活,但是代码量大,存在重复的代码比较多:声明式的比编程式的更灵活.编程式主要使用transactionTemplate.省略了部分的提交,回滚,一系列的事务对象定义,需注入事务管理对象:声明式:主要使用TransactionProxyFactoryBean,围绕Poxy的动态代理,能够自动的提交和回滚事务.统观spring事务,围绕着两个核心PlatformTransactionManager和TransactionSt

一.Propagation (事务的传播属性) Propagation : key属性确定代理应该给哪个方法增加事务行为.这样的属性最重要的部份是传播行为.有以下选项可供使用:PROPAGATION_REQUIRED--支持当前事务,如果当前没有事务,就新建一个事务.这是最常见的选择.PROPAGATION_SUPPORTS--支持当前事务,如果当前没有事务,就以非事务方式执行.PROPAGATION_MANDATORY--支持当前事务,如果当前没有事务,就抛出异常.PROPAGATION_RE

1 初步理解 理解事务之前,先讲一个你日常生活中最常干的事:取钱. 比如你去ATM机取1000块钱,大体有两个步骤:首先输入密码金额,银行卡扣掉1000元钱:然后ATM出1000元钱.这两个步骤必须是要么都执行要么都不执行.如果银行卡扣除了1000块但是ATM出钱失败的话,你将会损失1000元:如果银行卡扣钱失败但是ATM却出了1000块,那么银行将损失1000元.所以,如果一个步骤成功另一个步骤失败对双方都不是好事,如果不管哪一个步骤失败了以后,整个取钱过程都能回滚,也就是完全取消所有操作的话

Spring声明式事务让我们从复杂的事务处理中得到解脱.使得我们再也无需要去处理获得连接.关闭连接.事务提交和回滚等这些操作.再也无需要我们在与事务相关的方法中处理大量的try…catch…finally代码. 我们在使用Spring声明式事务时,有一个非常重要的概念就是事务属性.事务属性通常由事务的传播行为,事务的隔离级别,事务的超时值和事务只读标志组成.我们在进行事务划分时,需要进行事务定义,也就是配置事务的属性. Spring在TransactionDefinition接口中定义这些属性,

1.Spring声明式事务配置的五种方式 前段时间对Spring的事务配置做了比较深入的研究,在此之前对Spring的事务配置虽说也配置过,但是一直没有一个清楚的认识.通过这次的学习发觉Spring的事务配置只要把思路理清,还是比较好掌握的. 总结如下: Spring配置文件中关于事务配置总是由三个组成部分,分别是DataSource.TransactionManager和代理机制这三部分,无论哪种配置方式,一般变化的只是代理机制这部分. DataSource.TransactionManage

通过这篇文章,你将学习到Spring框架中中事务的传递 简介 在处理Spring管理的事务时,开发人员可以以传播的方式定义事务的行为.换句话说,开发人员能够决定业务方法如何被封装在逻辑和物理事务中.来自不同Spring bean的不同方法可以在相同的事务范围或分割为多个嵌套的事务中执行.这可能导致像内部事务产生的结果如何影响外部事务的细节.我们将在下一节中看到Spring中不同的传播机制的不同行为. 本教程将仅关注事务的传播机制行为.Spring事务的其他方面的细节,你可以参考其他的教程或Spr

从InfrastructureAdvisorAutoProxyCreator的层次结构中可以看到,InfrastructureAdvisorAutoProxyCreator间接实现了SmartInstantiationAwareBeanPostProcessor,而SmartInstantiationAwareBeanPostProcessor又继承自InstantiationAwareBeanPostProcessor,也就是说在Spring中,所有bean实例化时Spring都会保证调用其p