从Spring事务的隔离级别提及

隔离级别（isolation）定义了事务并发的隔离程度。

数据隔离级别分为不一样的四种：

• Serializable ：最严格的级别，事务串行执行，资源消耗最大；
• REPEATABLE READ ：保证了一个事务不会修改已经由另外一个事务读取但未提交（回滚）的数据。避免了“脏读取”和“不可重复读取”的状况，可是带来了更多的性能损失。
• READ COMMITTED :大多数主流数据库的默认事务等级，保证了一个事务不会读到另外一个并行事务已修改但未提交的数据，避免了“脏读取”。该级别适用于大多数系统。
• Read Uncommitted ：保证了读取过程当中不会读取到非法数据。

上面的解释其实每一个定义都有一些拗口，其中涉及到几个术语：脏读、不可重复读、幻读。

这里解释一下：

• 脏读（Dirty reads）——脏读发生在一个事务读取了另外一个事务改写但还没有提交的数据时。若是改写在稍后被回滚了，那么第一个事务获取的数据就是无效的。
• 不可重复读（Nonrepeatable read）——不可重复读发生在一个事务执行相同的查询两次或两次以上，可是每次都获得不一样的数据时。这一般是由于另外一个并发事务在两次查询期间进行了更新。
• 幻读（Phantom read）——幻读与不可重复读相似。它发生在一个事务（T1）读取了几行数据，接着另外一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些本来不存在的记录。

不可重复读的重点是修改:

• 一样的条件, 你读取过的数据, 再次读取出来发现值不同了。

读的重点在于新增或者删除：

• 一样的条件, 第1次和第2次读出来的记录数不同。

从控制的角度来看, 二者的区别就比较大：

• 对于前者, 只须要锁住知足条件的记录。
• 对于后者, 要锁住知足条件及其相近的记录。

一个对照关系表： Dirty reads non-repeatable reads phantom reads Serializable 不会 不会 不会 REPEATABLE READ 不会 不会 会 READ COMMITTED 不会 会 会 Read Uncommitted 会 会 会

因此最安全的，是Serializable，可是伴随而来也是高昂的性能开销。 另外，事务经常使用的两个属性：readonly和timeout 一个是设置事务为只读以提高性能。 另外一个是设置事务的超时时间，通常用于防止大事务的发生。仍是那句话，事务要尽量的小！

最后引入一个问题： 一个逻辑操做须要检查的条件有20条，可否为了减少事务而将检查性的内容放到事务以外呢？

不少系统都是在DAO的内部开始启动事务，而后进行操做，最后提交或者回滚。这其中涉及到代码设计的问题。小一些的系统能够采用这种方式来作，可是在一些比较大的系统， 逻辑较为复杂的系统中，势必会将过多的业务逻辑嵌入到DAO中，致使DAO的复用性降低。因此这不是一个好的实践。

来回答这个问题：可否为了缩小事务，而将一些业务逻辑检查放到事务外面？

答案是：对于核心的业务检查逻辑，不能放到事务以外，并且必需要做为分布式下的并发控制！

一旦在事务以外作检查，那么势必会形成事务A已经检查过的数据被事务B所修改，致使事务A徒劳无功并且出现并发问题，直接致使业务控制失败。

因此，在分布式的高并发环境下，对于核心业务逻辑的检查，要采用加锁机制。 好比事务开启须要读取一条数据进行验证，而后逻辑操做中须要对这条数据进行修改，最后提交。 这样的一个过程，若是读取并验证的代码放到事务以外，那么读取的数据极有可能已经被其余的事务修改，当前事务一旦提交，又会从新覆盖掉其余事务的数据，致使数据异常。 因此在进入当前事务的时候，必需要将这条数据锁住，使用for update就是一个很好的在分布式环境下的控制手段。

一种好的实践方式是使用编程式事务而非生命式，尤为是在较为规模的项目中。对于事务的配置，在代码量很是大的状况下，将是一种折磨，并且人肉的方式，绝对不能避免这种问题。

将DAO保持针对一张表的最基本操做，而后业务逻辑的处理放入manager和service中进行，同时使用编程式事务更精确的控制事务范围。 特别注意的，对于事务内部一些可能抛出异常的状况，捕获要谨慎，不能随便的catch Exception 致使事务的异常被吃掉而不能正常回滚。