关于Spring事务<tx:annotation-driven/>的理解(Controller可以使用@Transactional)

    在使用SpringMvc的时候,配置文件中我们经常看到 annotation-driven 这样的注解,其含义就是支持注解,一般根据前缀 tx、mvc 等也能很直白的理解出来分别的作用。<tx:annotation-driven/> 就是支持事务注解的(@Transactional) 、<mvc:annotation-driven> 就是支持mvc注解的,说白了就是使Controller中可以使用MVC的各种注解。

    首先,<tx:annotation-driven/>  会有一个属性来指定使用哪个事务管理器,如:<tx:annotation-driven transaction-manager="transactionManager" />。然后事务管理器 transactionManager 会引用 dataSource (如果我们使用JPA或Hibernate,也需要指定一个 entityManagerFactory ),dataSouce 肯定就是直接对数据库的了。

    这样逐层引用下去,所以我们使用@Transactionl 注解可以控制事务就通俗易懂了。另外要提一下的就是 spring 是使用 aop 通过 asm 操作java字节码的方式来实现对方法的前后事务管理的。

    说到这里,已经有了对 <tx:annotation-driven/> 的简单理解,那我们是否就可以在程序中所有被spring管理的类上都可以使用@Transactional注解了呢,在Service上可以使用@Transactional 注解这个是肯定的了,那总有些人也想弄明白能否在Controller 使用?答案显然是“不一定”的(与时间配置有关),下面做下解释:

在 spring-framework-reference.pdf 文档上有这样一段话:

<tx:annotation-driven/> only looks for @Transactional on beans in the same application context it is defined in. This means that, if you put <tx:annotation-driven/> in a WebApplicationContext for a DispatcherServlet, it only checks for @Transactional beans in your controllers, and not your services. 

意思就是:<tx:annoation-driven/>只会查找和它在相同的应用上下文件中定义的bean上面的@Transactional注解,如果你把它放在Dispatcher的应用上下文中,它只检查控制器(Controller)上的@Transactional注解,而不是你services上的@Transactional注解。

    所以,可以确定的是我们是可以在Controller上使用事务注解的,但是我们不推荐这样做(本人也从来没有这样做过),这里只是为了说明spring对<tx:annotation-driven/>的使用。

时间: 2024-09-23 15:41:12

关于Spring事务&lt;tx:annotation-driven/&gt;的理解(Controller可以使用@Transactional)的相关文章

spring事务管理器的源码和理解

以前说了大多的原理,今天来说下spring的事务管理器的实现过程,顺带源码干货带上. 其实这个文章唯一的就是带着看看代码,但是前提你要懂得动态代理以及字节码增强方面的知识(http://blog.csdn.net/xieyuooo/article/details/7624146),关于annotation在文章:http://blog.csdn.net/xieyuooo/article/details/8002321 也有说明,所以本文也就带着看看代码而已. 关于annotation这里就不说了

spring 事务管理让我费解的地方

问题描述 在用springmvc时,用到了spring事务管理<beanid="dataSource"class="org.apache.commons.dbcp.BasicDataSource"destroy-method="close"><propertyname="driverClassName"><value>${jdbc.driver}</value></prop

Spring事务配置的五种方式和spring里面事务的传播属性和事务隔离级别

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

Spring事务配置的五种方式(转自robbie的博客)

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

Spring事务配置的五种方式 巨全!不看后悔,一看必懂!

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

Spring事务管理--多个ORM框架在使用时的情况分析

   公司的项目已经接近尾声了,总结一下项目中用到的技术,我发现项目中的有些东西还是挺模糊的,只是知道这么用就行了.并不清楚其中的原理.由于公司的项目比较老,是7年前的一个项目了,中间一直有人在维护,也是在这个过程中不断融入了新的东西,比如就项目的持久化这块来说,就用了ibatis.mybatis.hibernate.spring JDBC四种混合的框架.究其原因只能说是历史遗留问题,就不做过多的解释了.但是这么多持久化的框架如何协同工作的,尤其是事务的控制,一个系统中使用如此多的持久化框架是,

spring事务不生效

问题描述 遇到了一个spring配置事务不能生效的问题,在网上查了一下各种解决方案,但还是不能解决,不知道问题根源在哪里,请各位大神指点,非常感谢.<bean id="dataSource" class="org.logicalcobwebs.proxool.ProxoolDataSource"><property name="driver">......<bean id="mySessionFactory

Spring 事务管理高级应用难点剖析: 第 3 部分

本文是"Spring 事务管理高级应用难点剖析" 系列文章的第 3 部分,作者将继续深入剖析在实际 Spring 事务管理应用中容易遇见的一些难点,包括在使用 Spring JDBC 时如果直接获取 Connection,哪些情况会造成数据连接的泄漏与如何应对,以及除 Spring JDBC 外,其它数据访问技术数据连接泄漏的应对方案.   概述 对于应用开发者来说,数据连接泄漏无疑是一个可怕的梦魇.如果存在数据连接泄漏问题,应用程序将因数据连接资源的耗尽而崩溃,甚至还可能引起数据库的

Spring 事务管理高级应用难点剖析: 第 2 部分

本文是"Spring 事务管理高级应用难点剖析" 系列文章的第 2 部分,作者将继续深入剖析在实际 Spring 事务管理应用中容易遇见的一些难点,包括混合使用多种数据访问技术(如 Spring JDBC + Hibernate)的事务管理问题,以及通过 Spring AOP 增强的 Bean 存在的一些比较特殊的情况. 联合军种作战的混乱 Spring 抽象的 DAO 体系兼容多种数据访问技术,它们各有特色,各有千秋.像 Hibernate 是非常优秀的 ORM 实现方案,但对底层