代码改变世界

事务不回滚

2016-04-29 14:19  夜半花开  阅读(2429)  评论(0)  编辑  收藏  举报

代码写法：

1 @Transactional(propagation = Propagation.REQUIRED, rollbackFor = { Exception.class })
2     public void delRules(Integer id,String type) throws Exception {
3         ruleProductMapper.delRuleProductByRuleId(id, type);
4         ruleMapper.deleteByPrimaryKey(id);
5     }

出现问题：手动new出异常后，事务不回滚

解决：原因是表的引擎是MySQL默认的myisam而不是Innodb；

java环境中的事物采用spring的xml配置，在service中如果抛出Exception异常，则事物不能回滚。

原来默认spring只在发生未被捕获的runtimeexcetpion时才回滚。spring的事务边界是在调用业务方法之前开始的，业务方法执行完毕之后来执行commit or rollback(Spring默认取决于是否抛出runtime异常，但是可以修改，见解决方法2). 如果抛出runtime exception的话，事务会回滚。 一般不需要在业务方法中catch异常，如果非要catch，在做完你想做的工作后（比如关闭文件等）一定要抛出runtime exception，否则spring会将你的操作commit,这样就会产生脏数据.

解决办法有两种：

1、  service中不抛出Exception，使用try捕获后抛出runtimeexcetpion；

2、  修改spring的配置文件

       <tx:method name=”save*” rollback-for=”java.lang.Exception”/>

3.TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();语句，手动回滚，这样上层就无需去处理异常. 在service中增加数据库回滚，不推荐使用。

以下内容转自：http://my.oschina.net/crazyharry/blog/338468

摘要 当你使用了mysql数据库管理数据.事务提交交给代码完成，然而当发生错误的时候事务未回滚。看下这篇文章也许你就明白了

MySQL 事务回滚 代码 事务未回滚

 

目录[-]

问题来源

有一小伙伴，事务提交是加在方法级上的。并且方法里写了几个更新数据库表的操作。然而当数据前几个顺利执行通过后，发现最后一个操作并未通过。按照一般的事务管理规则，此刻是应该触发事务回滚的。然而并没有触发，前两次操作成功地写入了数据库，最后一次失败告终。

问题追踪

项目大体是使用mysql数据库，管理事务是在spring中完成。其实这里跟开发语言没有任何关系，无论使用什么语言什么框架，都有可能遇到此类问题。分别以下述步骤进行了一番分析：

  1. 查看源码，发现没有逻辑错误

  2. 比对其他方法，业务异常

  3. 到目前为止只能怀疑数据库了

    1. 查看数据库的配置也无什么异常分别是InnoDB以及utf-8编码

    2. 比对操作的表，发现出错的表里使用的引擎（engine）是MyISAM，跟其他表的不一样

结论

mysql一共提供了两种引擎（engine），即InnoDB和MyISAM。查看两种引擎的区别不难发现：

  • InnoDB supports transactions which is not supported by tables which use MyISAM storage engine.

  • InnoDB has row-level locking, relational integrity i.e. supports foreign keys, which is not possible in MyISAM.

  • InnoDB ‘s performance for high volume data cannot be beaten by any other storage engines available.

另外还有一个分析对比，选择合适的引擎：

                                             My ISAM    InnoDB
Required full text Search                      Yes       5.6+
Require Transactions                                     Yes
frequent select queries                        Yes      
frequent insert,update,delete                            Yes
Row Locking (multi processing on single table)           Yes
Relational base design                                   Yes