Transaction

本文 存属提醒我自己不要忘记的事情。也是向大家展示 Hasor 对于 JDBC 方面即将的又一个重大的进步。目前该方案还在实施中。 前段时间闲着没事分析了下 Spring JDBC ，觉得 Spring JDBC 的设计实在是太绝了，于是就拷贝了 Spring JDBC 的关键接口，然后开始了迁移工作，最后 Hasor - JDBC 问世。 可是 Hasor JDBC 至今仍有一个重大问题没有搞定，那就是事务控制。 虽然可以通过暴露 Connection 简单的加装一个 Aop 拦截器在配合 @Tar... 注解可以完成任务。但是我觉得我有点完美主义了。最近脑袋里一直都是 Spring 那套事务控制体系，我有种冲动在 Hasor 中重新实现这一套事务控制体系。 简介一下 Spring 事务方面的内容，Spring 对于事务方面支持 7种事务传播属性。我用这个接口表示它们： /** * 事务传播属性 * @version : 2013-10-30 * @author 赵永春(zyc@hasor.net) */ public enum TransactionBehavior { /** * 加入已有事务 * <p><i><b>释意</b></i>：尝试加入已经存在的事务中，如果没有则开启一个新的事务。*/ PROPAGATION_REQUIRED, /** * 独立事务 * <p><i

原文地址： Spring Transaction + MyBatis SqlSession事务管理机制研究学习 线上的系统中，使用的是Spring+Mybatis+Mysql搭建的框架，由于客户需要，最近一直在对性能提升部分进行考虑，主要是涉及Mysql的一些重要参数的配置学习，以及Spring事务管理机制的学习，因为通过观察服务器日志，发现在这两部分的时候耗时比较严重，特别是进行mysql事务提交的时候，项目源码中使用了Spring的声明式事务，即通过@Transactional注解来控制事务的开启与提交，这两天看了一些关于Spring Transaction事务的一些文章，也debug了源码，总算有点心得和疑问，这里简单的整理一下。 在Spring的配置文件中，我们使用了"org.springframework.jdbc.datasource.DataSourceTransactionManager"对事务进行管理，翻开 DataSourceTransactionManager的源码，我们看到 DataSourceTransactionManager继承了AbstractPlatformTransactionManager（抽象的事务管理器）， DataSourceTransactionManager 重写了其中的一些方法，具体每个方法的作用，限于篇幅 ，本文不再赘述 ，这里

1，TransactionAutoConfiguration ①，这是SpringBoot 的事务注解自动配置类，位于spring-boot-autoconfigure jar下。 ②，@ConditionalOnClass(PlatformTransactionManager.class) 通过这一行，我们知道只有在类路径下有这个类存在时，事务自动配置类才生效 ③，PlatformTransactionManager 位于spring-tx jar下 2，spring-boot-starter-jdbc.jar 的依赖 3，spring-boot-starter-data-jpa ①，spring-boot-starter-data-jpa 依赖于spring-boot-starter-jdbc 4，mybatis-spring-boot-starter ①，mybatis-spring-boot-starter 依赖于spring-boot-starter-jdbc 5，总结 ①，因为，jdbc，jpa，mybatis 的starter 都会依赖到 spring-tx.jar 所以事务注解会生效。 ②，如有不对，还请大家指出 来源： oschina 链接： https://my.oschina.net/u/3574106/blog/1819352

本文是<实现 Spring 的事务控制>系列文章中一篇。本文假设读者已经阅读并理解《 实现 Spring 的事务控制，之一（必要的概念） 》文中所涉及的概念（ 当前连接 、 引用计数 ），以及数据库连接的（ new状态 ） PROPAGATION_SUPPORTS（跟随环境） 定义： 是指 Spring 容器中如果当前没有事务存在，就以非事务方式执行；如果有就使用当前事务。 解释： SUPPORTS 行为是 Spring 事务传播属性中最简单的一种行为。SUPPORTS 行为本质上强调了“不作为”。如下图： 似乎我不需要多解释这张图后面的工作原理，大家只要记得。无论是什么行为下，开启事务和递交事务都会对当前连接的引用计数有++ -- 操作就可以了。 SUPPORTS 行为带给我们的结果是，如果当前环境中存在事务，那么就用这个环境的事务。否则就什么都不用。这种行为下不会对事务进行任何操作。 来源： oschina 链接： https://my.oschina.net/u/1166271/blog/200384

1Spring事务传播行为 所谓事务传播行为就是多个事务方法相互调用时，事务如何在这些方法间传播。Spring支持7种事务传播行为 PROPAGATION_REQUIRED （加入已有事务） 如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中。这是最常见也是默认的方式。 PROPAGATION_SUPPORTS （跟随环境） 支持当前事务，如果当前没有事务，就以非事务方式执行。 PROPAGATION_MANDATORY （需要事务） 使用当前的事务，如果当前没有事务，就抛出异常。 PROPAGATION_REQUIRES_NEW （独立事务） 新建事务，如果当前存在事务，把当前事务挂起。 PROPAGATION_NOT_SUPPORTED （非事务方式） 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。 PROPAGATION_NEVER （排除事务） 以非事务方式执行，如果当前存在事务，则抛出异常。 PROPAGATION_NESTED （嵌套事务） 如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与PROPAGATION_REQUIRED类似的操作。 Spring默认的事务传播行为是PROPAGATION_REQUIRED，它适合于绝大多数的情况。假设ServiveX#methodX()都工作在事务环境下