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_REQUIRED类似的操作。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.数据不合法性的情况。 脏读：事务A读到了事务B修改而未提交的数据。(ISOLATION_READ_COMMITTED解决) 不可重复读：事务A读一数据在更新前却被事务B更新了。(乐观锁解决) 重复读问题：事务A读字段f的数据并被快照下,此时事务B更新字段f的数据,事务A再读时从快照中读的是原来重复的数据。 5.3种事务配置。 1)原始古老xml配置。(配置较繁琐,配置内容较多,一般不再使用) 1234567891011121314151617181920212223/这里是:交由jdbc管理事务的配置。 PROPAGATION_REQUIRED,readOnly PROPAGATION_REQUIRED,readOnly PROPAGATION_REQUIRED 2)基于schema的aop命名空间xml配置。(环境低于JDK5.0使用不了annotation时,一般使用此配置,较简洁) 12345678910111213141516/这里是:交由hibernate管理事务的配置。3)基于annotation的Transactional注释配置。(配置简单,推荐使用,但须JDK5.0及以上) 1234567891011121314151617181920/这里是:交由hibernate管理事务的配置。/默认使用id为transactionManager的bean做为事务管理器/也可以这样指明 Transactionalpublic class UserService public void saveUser(User entity) ./增删改操作默认为类的事务属性配置 Transactional(readOnly = true) public User getUser(Long id) ./读取操作单独配置事务属性只读 Transactional(readOnly = true) public List findUser(String name) ./读取操作单独配置事务属性只读6.常见的错误： 是希望在service方法中catch到spring的异常,抛出一个自定义异常,但是不继承自DataAccessException的。可惜的是这样做是catch不到spring的异常的。 原因： spring是靠捕获方法抛出的DataAccessException来处理事务的,若被我们自己catch到了,s