代码写法：
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数据库，管理事务是在spring中完成。其实这里跟开发语言没有任何关系，无论使用什么语言什么框架，都有可能遇到此类问题。分别以下述步骤进行了一番分析：
-
查看源码，发现没有逻辑错误
-
比对其他方法，业务异常
-
到目前为止只能怀疑数据库了
-
查看数据库的配置也无什么异常分别是InnoDB以及utf-8编码
-
比对操作的表，发现出错的表里使用的引擎（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