1.问题提出：
在service中写方法时，抛出了一个Exception, 本来目的是为了让事务回滚， 但事实上没有回滚，产生了脏数据。
代码如下：
@Override
@Transactional
public void insertInSingle(String type, MobileEditInDTO dto) throws Exception {
MaterialOtherInSingle otherInSingle = otherInService.findEntityByProperty("tableNo", tableNo);
//其他入库单表头
otherInSingle.setServiceTypeID(serviceTypeService.getServiceType(dto.getServiceTypeId()));
otherInSingle.setInCome(storageTypeService.getStorageType(dto.getStorageTypeId()));
otherInSingle.setInStorageDate(dto.getInDate());
throw new Exception(111);
}
在这个方法中用hql获得了一个持久态对象，并设置了新的属性，在最后演示的时候抛出了异常，但是最后并未回滚。
2.问题分析
在这个方法中加入了@Transactional注解，声明了这是一个事务，其原理就是AOP。平时我们都是这么做的，但是并不是很清楚原理是什么。
注解其实只是一个声明，真正的目的在声明之后这个方法成为了一个连接点，说到连接点又不得不说AOP,
AOP说简单点其实就是一个动态代理，我们service之所以要先声明接口再有一个实现类其实很大程度上为了实现动态代理，实现动态代理之后我们可以省去很多在方法层面上重复的代码。
不理解的请自行百度关键词: AOP, 动态代理，这个东西很复杂一下子也说不清楚（其实我也不是很懂）。
说回来这个@Transactional，它的切入点（PointCut）其实就是抛异常，在抛出异常的时候调用增强处理（Advice）中的方法将事务回滚掉，但是这个抛异常抛的不是普通的自Exception中继承过来的异常，
unchecked exception回滚。也就是默认对RuntimeException()异常或是其子类进行事务回滚。虽然RuntimeException继承自Exception，但是切入点要更具体一些。
当然如果要让所有Exception都回滚，在@Transactional(rollbackFor = Exception.class) 上加个参数就好了。
但是要注意的事，如果声明了@Transactional，但是又在方法里面自己捕获了异常，也就是try catch掉了，那就不会回滚了，因为切入点根本没捕获到，也谈不上调用增强处理中的方法了。
3.问题解决
上面啰嗦了这么多，解决这个问题无非就是两个办法：
1.抛出RuntimeException
2.抛出Exception，同时在事务声明中加上@Transactional(rollbackFor = Exception.class)
如果有写到不对的地方，欢迎多多指正
还要再说明一点，在controller中调用service的这个已经解决的方法是可以try catch的，不用担心不会回滚，因为已经被aop监听到了。