Spring事务小结.doc

Spring事务小结 1.spring中事务配置属性以及@Transaction对应的默认值。一般使用默认值即可,特殊情况自定义。 1)事务传播行为(propagation)：默认PROPAGATION_REQUIRED 2)事务隔离级别(isolation)：默认ISOLATION_DEFAULT(数据库默认的隔离级别) 3)只读还是读写(readonly)：默认读写事务。 4)异常发生时回滚还是提交(rollback-for/no-rollback-for)：默认checked异常引发回滚,unchecked异常继续提交。 2.spring的7种事务传播行为。一般使用PROPAGATION_REQUIRED即可。 PROPAGATION_REQUIRED：如果当前有事务则支持当前事务;如果当前没有事务,新建一个事务。PROPAGATION_NESTED：如果当前存在事务,则在嵌套事务内执行;如果当前没有事务,新建一个事务。嵌套事务。③PROPAGATION_REQUIRES_NEW：如果当前存在事务,则把当前事务挂起;如果当前有事务,建一个事务。 PROPAGATION_SUPPORTS：如果当前有事务,则支持当前事务;如果当前没有事务,以非事务方式执行。 PROPAGATION_MANDATORY：如果当前有事务,则支持当前事务;如果当前没有事务,抛出异常。 PROPAGATION_NOT_SUPPORTED：如果当前有事务,则把当前事务挂起,如果当前没有事务,以非事务方式执行。 PROPAGATION_NEVER：如果当前有事务,则抛出异常;如果当前没有事务,以非事务方式执行。 存在两事务的场景时,传播行为分析。 123456789101112131415 存在两事务的场景： ServiceA { //事务属性配置为 PROPAGATION_REQUIRED void A() { .....; ServiceB.B(); .....; } } ServiceB { //事务属性配置为 ,②,③ void B() { ......; } } 1)B()事务为时,B()中发生异常,整个事务回滚;A()中B()执行后的其他操作发生异常,整个事务回滚;A(),B()中都正常,整个事务成功。因此为完全互相影响的事务：内层异常时可以回滚外层的操作,外层异常时也可以回滚内层的操作。一般使用,只有当内层事务需要做分支处理时,才会使用嵌套事务。 2)B()事务为时,A()和B()都不会因为对方的执行情况而影响到结果,是完全的两个事务。因此为完全互不影响的事务：内层异常时不可以回滚外层的操作,外层异常时也不可以回滚内层的操作。基本不会使用,因为内层提交了,外层回滚了,会出现脏数据。 3)B()事务为时,B()中发生异常回滚时只会回滚到B()当前,若需继续回滚A()中其他的操作,必须catch后抛exception;A()中B()执行后的其他操作发生异常整个事务回滚。因此为部分互相影响的事物：内层异常时根据自己的操作来决定回滚整个事务与否,外层异常时可以回滚内层的操作。使用嵌套事务的前提是:如果子事务有异常时需要做分支处理并决定是否回滚。否则就使用:如果子事务有异常,直接回滚。 3.4种事务隔离级别。一般使用ISOLATION_READ_COMMITTED即可。 1)ISOLATION_READ_UNCOMMITTED：有脏读,不可重复读,虚读3种问题。并发稍大点的逻辑严格的系统应避免使用。 2)ISOLATION_READ_COMMITTED：有不可重复读,虚读2种问题。适合大多数系统。 3)ISOLATION_REPEATABLE_READ：有重复读问题。因为不能完全保证数据合法性(虚读),性能损失较大。 4)ISOLATION_SERIALIZABLE：没有问题。类似银行对事务要求苛刻的系统使用。完全保证数据合法性,高昂的性能开销。 备注：为了解决脏读和不可重复读两个问题,又不想使用ISOLATION_REPEATABLE_READ来解决不可重复读(因为性能损失),当我们所做的系统中db只由一个app独享时,可以通过乐观锁解决不可重复读问题。也就是说：通常一般的系统设置事务隔离级别为ISOLATION_READ_COMMITTED,若希望避免不可重复读问题,可加上乐观锁解决。事务要求苛刻的系统使用ISOLATION_SERIALIZABLE,其他2项一般不使用。 4.数据不合法性的情况。