Transaction

最近在用spring-data-jpa做事务处理时，由于两个事务都处理了同一个表，其中一个事务加锁，另外一个事务不加锁，于是在调用的另外一个事务中使用了嵌套的方式，但是运行却报 JpaDialect does not support savepoints - check your JPA provider's capabilities 后经查实，原来Hibernate/JPA并不能实现嵌套事务，嵌套事务仅仅在JDBC级别支持，对于Hibernate/JPA要实现嵌套事务，也仅仅在dialect为Oracle的情况下才完全实现。 那怎么办？那当然是使用JDBC事务控制咯，因此你可以使用JdbcTemplate或者mybatis数据库框架进行控制。 <tx:annotation-driven transaction-manager="transactionManager"/> <bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate"> <property name="dataSource" ref="dataSource"></property> </bean> 这个时候，只需要在方法上添加 @Transactional(propagation=Propagation.NESTED

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本文是<实现 Spring 的事务控制>系列文章中一篇。本文假设读者已经阅读并理解《 实现 Spring 的事务控制，之一（必要的概念） 》文中所涉及的概念（ 当前连接 、 引用计数 ），以及数据库连接的（ new状态 ） RROPAGATION_REQUIRES_NEW（独立事务） 定义： 如果当前存在事务则挂起当前事务，并开启一个全新的事务。新事务与已存在的事务之间彼此没有关系。 解释： REQUIRES_NEW 行为强调了独立性。它保证了每个事务状态管理范围内锁使用的数据库连接是彼此不一样的。例如独立事务会满足“A事务中存在B事务，当B事务递交的时候不影响A事务。A，B两个事务之间不存在相互关联关系。“ 时间 事务1 事务2 T1 开始事务 T2 操作1... T3 开始事务 T4 操作2... T5 递交事务 T6 回滚事务 定义中提到”挂起事务“这句话怎么理解？ 所谓“挂起”指的是将当前线程使用的数据库连接，暂时保存起来不在使用。取而代之的是一个新的数据库库连接。 与挂起相对应的还有一个“恢复事务”，它们的操作是成对出现的。恢复就是将当前数据库连接释放掉，然后将以前挂起的那个数据库连接重新设为当前数据库连接。 REQUIRES_NEW 行为由于出现了“挂起”这样的操作

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 提到Hive一般都会想到，Hive是数据仓库，支持类SQL查询，有很多语法支持，可以嵌套MR，写Transform、写UDF/UDAF等， 但是，不支持更新操作 。所以Hive的常见也一般都是一次写入，频繁读取。从Hive 0.13开始，加入了ACID的新feature，但是0.13的时候还不支持insert、update和delete操作，我也并没有欣然的当小白鼠。 目前我们平台使用hive1.2.1的社区版，业务上也遇到了需要更新的场景。也是继续调研Transaction的特性。Transaction有几个依赖条件： 1、只支持ORCFile 2、默认关闭，需要自己开启 3、表必须分桶 4、0.14开始支持insert、update和delete 5、必须加入一大堆配置（下文） 一言不合就上个Demo： +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1、建表： create table test_trancaction (user_id Int,name String) clustered by (user_id) into 3 buckets stored as orc TBLPROPERTIES ('transactional'=

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 基于PostgreSQL9.4 9.3中文文档： http://58.58.27.50:8079/doc/html/9.3.1_zh/mvcc.html 9.4中文文档： http://www.postgresql.org/docs/9.4/static/mvcc.html 本文描述PostgreSQL数据库系统在多个会话试图同时访问同一数据时的表现。并发控制的目标是为所有会话提供高效的访问，同时还要维护严格的数据完整性。每个数据库应用开发人员都应该熟悉本话题。 PostgreSQL的MVCC与锁 PostgreSQL为开发者提供了丰富的对数据并发访问进行管理的工具。在内部， PostgreSQL利用多版本并发控制(MVCC)来维护数据的一致性 。这就意味着当检索数据时，每个事务看到的都只是一小段时间之前的数据快照(一个 数据库版本 )，而不是数据的当前状态。这样，如果对每个数据库会话进行 事务隔离 ，就可以避免一个事务看到其它并发事务的更新而导致不一致的数据。MVCC通过避开传统数据库系统锁定的方法，最大限度地减少锁竞争以允许合理的多用户环境中的性能。 使用MVCC与使用锁定模式相比较的优缺点： 在MVCC里，对检索(读)数据的锁请求与写数据的锁请求不冲突，所以读不会阻塞写，而写也从不阻塞读。甚至当通过创新的

Transaction 也就是所谓的事务了，通俗理解就是一件事情。从小，父母就教育我们，做事情要有始有终，不能半途而废。 事务也是这样，不能做一般就不做了，要么做完，要么就不做。也就是说，事务必须是一个不可分割的整体，就像我们在化学课里学到的原子，原子是构成物质的最小单位。于是，人们就归纳出事务的第一个特性： 原子性（Atomicity） 。我靠，一点都不神秘嘛。 特别是在数据库领域，事务是一个非常重要的概念，除了原子性以外，它还有一个极其重要的特性，那就是： 一致性（Consistency） 。也就是说，执行完数据库操作后，数据不会被破坏。打个比方，如果从 A 账户转账到 B 账户，不可能因为 A 账户扣了钱，而 B 账户没有加钱吧。如果出现了这类事情，您一定会非常气愤，什么 diao 银行啊！ 当我们编写了一条 update 语句，提交到数据库的一刹那间，有可能别人也提交了一条 delete 语句到数据库中。也许我们都是对同一条记录进行操作，可以想象，如果不稍加控制，就会出大麻烦来。我们必须保证数据库操作之间是“隔离”的（线程之间有时也要做到隔离），彼此之间没有任何干扰。这就是： 隔离性（Isolation） 。要想真正的做到操作之间完全没有任何干扰是很难的，于是乎，每天上班打酱油的数据库专家们，开始动脑筋了，“我们要制定一个规范，让各个数据库厂商都支持我们的规范！”

本文是<实现 Spring 的事务控制>系列文章中一篇。本文假设读者已经阅读并理解《 实现 Spring 的事务控制，之一（必要的概念） 》文中所涉及的概念（ 当前连接 、 引用计数 ），以及数据库连接的（ new状态 ） PROPAGATION_NOT_SUPPORTED （非事务方式） 定义： 是指如果存在事务则将这个事务挂起，并使用新的数据库连接。新的数据库连接不使用事务。 解释： NOT_SUPPORTED 行为是 Spring 为我们带来的一种特殊的事务控制行为。在这种行为下它保证了当前对数据库的操作是相当于 autoCommit 值为 true 。 我们回顾第一篇文章中提到的银行转账业务：“A账户可以转账给B账户，银行要求能看到当前实时的正在交易的笔数”。我们曾在《 REQUIRES_NEW - 独立事务 》一文中见到过如何实现这个需求。现在我在像大家介绍如何通过 使用 NOT_SUPPORTED 行为实现同样的业务。 时间 事务1（开启事务） 事务2（非事务） T1 开始事务 T2 挂起事务 T3 记录日志... T4 恢复事务 T5 转账500元 T6 挂起事 务 T7 记录日志 T8 恢复事务 T9 递交事务 我们先看事务1，在事务1中展示的是一个完整的转账业务功能。它被一个事务所环抱，这个事务保证了转账业务的正确执行。 下面我们看一看事务2中是如何处理日志记录的

本文是<实现 Spring 的事务控制>系列文章中一篇。本文假设读者已经阅读并理解《 实现 Spring 的事务控制，之一（必要的概念） 》文中所涉及的概念（ 当前连接 、 引用计数 ），以及数据库连接的（ new状态 ） PROPAGATION_MANDATORY（要求不存在事务） 定义： 如果当前有事务存在，就以事务方式执行；如果没有，就抛出异常。 解释： 解释 MANDATORY 行为是最好解释的行为之一。MANDATORY 强调了必须要有事务。这个行为与 NEVER行为工作方式一样，不同的是所判断的情况却正好是相反的。MANDATORY 行为下当前连接不具备事务，会抛出异常，这种行为一般很少使用。 工 作原理 来源： oschina 链接： https://my.oschina.net/u/1166271/blog/200959

本文是<实现 Spring 的事务控制>系列文章中一篇。本文假设读者已经阅读并理解《 实现 Spring 的事务控制，之一（必要的概念） 》文中所涉及的概念（ 当前连接 、 引用计数 ），以及数据库连接的（ new状态 ） PROPAGATION_NEVER（排除事务） 定义： 如果当前没有事务存在，就以非事务方式执行；如果有，就抛出异常。 解释： 解释 NEVER 行为是最好解释的行为之一。NEVER 强调了非事务。一旦发现有事务存在，往下连进行都不进行，直接抛出异常。至于工作原理我想就不用多介绍了把。 工 作原理 来源： oschina 链接： https://my.oschina.net/u/1166271/blog/200958

本文是<实现 Spring 的事务控制>系列文章中一篇。本文假设读者已经阅读并理解《 实现 Spring 的事务控制，之一（必要的概念） 》文中所涉及的概念（ 当前连接 、 引用计数 ），以及数据库连接的（ new状态 ） PROPAGATION_NESTED（嵌套事务） 定义： 在当前事务上开启一个子事务（Savepoint），如果递交主事务。那么连同子事务一同递交。如果递交子事务则保存点之前的所有事务都会被递交。 解释： 所谓嵌套事务，指的就是 NESTED 行为。这一点大家要格外注意。 这是由于“嵌套事务”这个词在 Spring 之后具备了多重含义。一种是指 Spring 提供的事务控制体系中那种基于多行为的嵌套事务控制策略。另外一种就是原汁原味 JDBC 提供给我们的嵌套事务。本文所提到的嵌套事务在没有特殊说明的情况下都是指后者。 好了回归正题，何为嵌套事务？ 先不看定义，我们从字面理解，所谓嵌套，是指一层套着另一层的意思。那么真实情况是否是这样的呢？先看一下下面这张表： 时间 事务1 事务2 T1 开始主事务 T2 操作1... T3 创建事务保存点 T4 操作2... T5 递交保存点 T6 操作3... T7 回滚主事务 上面这张表中列出了我们理想的事务递交方式。我们认为事务2递交不会影响到事务1。但是实际情况是错误的。 我们知道事务保存点的功能有点相当于“锚标记

写这篇博文的目的首先是与大家分享一下如何用更轻量化的办法去实现 Spring 那种完善的事务控制。 为什么需要嵌套事务？ 我们知道，数据库事务是为了保证数据库操作原子性而设计的一种解决办法。例如执行两条 update 当第二条执行失败时候顺便将前面执行的那条一起回滚。 这种应用场景比较常见，例如银行转帐。A账户减少的钱要加到B账户上。这两个SQL操作只要有一个失败，必须一起撤销。 但是通常银行转帐业务无论是否操作成功都会忘数据库里加入系统日志。如果日志输出与账户金额调整在一个事务里，一旦事务回滚日志也会跟着一起消失。这时候就需要嵌套事务。 时间 事务 T1 开始事务 T2 记录日志... T3 转账500元 T4 记录日志... T5 递交事务 为什么有了嵌套事务还需要独立事务？ 假设现在银行需要知道当前正在进行转账的实时交易数。 我们知道一个完整的转账业务会记录两次日志，第一次用以记录是什么业务，第二次会记录这个业务总共耗时。因此完成这个功能时我们只需要查询还未进行第二次记录的那些交易日志即可得出结果。 时间 事务1 事务2 T1 开始事务 T2 记录日志... T3 开始子事务 T4 转账500元 T5 递交子事务 T6 记录日志... T7 递交事务 分析一下上面这种嵌套事务就知道不会得出正确的结果，首先第一条日志会被录入数据库的先决条件是转账操作成功之后的递交事务。