Spring+SpringMVC 配置事务管理无效原因及解决方案。
2017-01-11 14:12
288 查看
spring4整合hibernate4事务不生效问题
其实Spring和SpringMVC俩个容器为父子关系,Spring为父容器,而SpringMVC为子容器。也就是说application.xml中应该负责扫描除@Controller的注解如@Service,而SpringMVC的配置文件应该只负责扫描@Controller,否则会产生重复扫描导致Spring容器中配置的事务失效。
在主容器中(applicationContext.xml),将Controller的注解排除掉
<context:component-scan base-package="com.feng.controller">
<context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller" />
</context:component-scan>
而在springMVC配置文件中将Service注解给去掉
<context:component-scan base-package="com.feng">
<context:include-filter type="annotation" expression="org.springframework.stereotype.Controller" />
<context:exclude-filter type="annotation" expression="org.springframework.stereotype.Service" />
</context:component-scan>
由ContextLoaderListener产生的是父容器(applicationContext.xml)
springMVC产生的是子容器(springMVC.xml)
如果子容器Controller进行扫描装配时装配了@Service注解的实例,
由于该实例理应由父容器进行初始化以保证事务的增强处理,所以此时得到的将是原样的Service(没有经过事务加强处理,故而没有事务处理能力。
经过测试,其实问题主要在于SpringMVC的配置文件扫包范围,Spring的配置文件就算也扫了@Controller注解,但是在SpringMVC会重新扫描一次,事务管理的Service只要没被重新扫描就不会出现事务失效问题
还有一种方式是将service层改用xml配置,其实这样做也是变相的让springmvc无法扫描service,而只能依赖父窗口也就是ServletContextListener来进行初始化,这样同样被赋予了事务性
其实Spring和SpringMVC俩个容器为父子关系,Spring为父容器,而SpringMVC为子容器。也就是说application.xml中应该负责扫描除@Controller的注解如@Service,而SpringMVC的配置文件应该只负责扫描@Controller,否则会产生重复扫描导致Spring容器中配置的事务失效。
在主容器中(applicationContext.xml),将Controller的注解排除掉
<context:component-scan base-package="com.feng.controller">
<context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller" />
</context:component-scan>
而在springMVC配置文件中将Service注解给去掉
<context:component-scan base-package="com.feng">
<context:include-filter type="annotation" expression="org.springframework.stereotype.Controller" />
<context:exclude-filter type="annotation" expression="org.springframework.stereotype.Service" />
</context:component-scan>
由ContextLoaderListener产生的是父容器(applicationContext.xml)
springMVC产生的是子容器(springMVC.xml)
如果子容器Controller进行扫描装配时装配了@Service注解的实例,
由于该实例理应由父容器进行初始化以保证事务的增强处理,所以此时得到的将是原样的Service(没有经过事务加强处理,故而没有事务处理能力。
经过测试,其实问题主要在于SpringMVC的配置文件扫包范围,Spring的配置文件就算也扫了@Controller注解,但是在SpringMVC会重新扫描一次,事务管理的Service只要没被重新扫描就不会出现事务失效问题
还有一种方式是将service层改用xml配置,其实这样做也是变相的让springmvc无法扫描service,而只能依赖父窗口也就是ServletContextListener来进行初始化,这样同样被赋予了事务性
相关文章推荐
- Spring+SpringMVC 配置事务管理无效原因及解决方案。
- Spring 配置事务管理无效(No Session found for current thread)原因及解决方案
- Spring+SpringMVC 配置事务管理无效原因
- Spring+SpringMVC配置事务管理无效原因及解决办法详解
- SpringMVC 配置事务管理无效的原因及解决方案
- spring+springMvc+mybatis配置事务管理
- Spring配置多数据源在配置事务后无效完美解决方案
- Spring配置多数据源在配置事务后无效完美解决方案
- Spring配置多数据源在配置事务后无效完美解决方案
- Spring配置多数据源在配置事务后无效完美解决方案
- spring mvc+hibernate 实现事务管理(配置文件版)
- spring mvc+hibernate 实现事务管理(配置文件版)
- Spring配置多数据源在配置事务后无效完美解决方案
- ShiroDbRealm 导致spring 事务配置无效原因分析
- Spring配置多数据源在配置事务后无效完美解决方案
- Spring配置多数据源在配置事务后无效完美解决方案
- spring+springMVC中使用@Transcational方式管理事务的配置方法
- Spring配置多数据源在配置事务后无效完美解决方案
- Spring配置多数据源在配置事务后无效完美解决方案
- Spring配置多数据源在配置事务后无效完美解决方案