备注一点：如果你catch住后继续向上throw，也是不会出现这种情况的。
引发了这个血案。这是上面意思呢？其实很好解释：在create准备return的时候，transaction已经被addPerson设置为rollback-only了，但是create方法给抓住消化了，没有继续向外抛出，所以create结束的时候，transaction会执commit操作，所以就报错了。看看处理回滚的源码：
private void processRollback(DefaultTransactionStatus status, boolean unexpected) { try { boolean unexpectedRollback = unexpected; try { triggerBeforeCompletion(status); if (status.hasSavepoint()) { if (status.isDebug()) { logger.debug("Rolling back transaction to savepoint"); } status.rollbackToHeldSavepoint(); } else if (status.isNewTransaction()) { if (status.isDebug()) { logger.debug("Initiating transaction rollback"); } doRollback(status); } else { // Participating in larger transaction if (status.hasTransaction()) { if (status.isLocalRollbackOnly() || isGlobalRollbackOnParticipationFailure()) { if (status.isDebug()) { logger.debug("Participating transaction failed - marking existing transaction as rollback-only"); } doSetRollbackOnly(status); } else { if (status.isDebug()) { logger.debug("Participating transaction failed - letting transaction originator decide on rollback"); } } } else { logger.debug("Should roll back transaction but cannot - no transaction available"); } // Unexpected rollback only matters here if we're asked to fail early if (!isFailEarlyOnGlobalRollbackOnly()) { unexpectedRollback = false; } } } catch (RuntimeException | Error ex) { triggerAfterCompletion(status, TransactionSynchronization.STATUS_UNKNOWN); throw ex; } triggerAfterCompletion(status, TransactionSynchronization.STATUS_ROLLED_BACK); // Raise UnexpectedRollbackException if we had a global rollback-only marker if (unexpectedRollback) { throw new UnexpectedRollbackException( "Transaction rolled back because it has been marked as rollback-only"); } } finally { cleanupAfterCompletion(status); } }
简单分析：addPerson()有事务，然后处理的时候有这么一句：
这个时候把参数unexpectedRollback置为false了，所以当create事务需要回滚的时候，如下：
所以，就之前抛出异常了，这个解释很合理了吧。因为之前事务被设置过禁止回滚了。然后遇到了这个问题，我们有没有解决办法呢？其实最简单的决绝办法是：
@Override public boolean addPerson(User user) { System.out.println(1 / 0); return false; }
因为有源码里这么一句话：status.isNewTransaction() 所以我尝试用一个新事务也是能解决这个问题的
@Transactional(propagation = Propagation.REQUIRES_NEW) @Override public boolean addPerson(User user) { System.out.println(1 / 0); return false; }
但有时候我们并不希望是这样子，怎么办呢？
这个时候其实可以不通过异常来处理，或者通过自定义异常的方式来处理。
**如果某个子方法有异常，spring将该事务标志为rollback only。**如果这个子方法没有将异常往上整个方法抛出或整个方法未往上抛出，那么改异常就不会触发事务进行回滚，事务就会在整个方法执行完后就会提交，这时就会造成Transaction rolled back because it has been marked as rollback-only的异常。
另外一种并不推荐的解决办法如下：
<property name="globalRollbackOnParticipationFailure" value="false" />
这个方法也能解决，但显然影响到全局的事务属性，所以极力不推荐使用。
如果isGlobalRollbackOnParticipationFailure为false,则会让主事务决定回滚，如果当遇到exception加入事务失败时，调用者能继续在事务内决定是回滚还是继续。然而，要注意是那样做仅仅适用于在数据访问失败的情况下且只要所有操作事务能提交
Tips：
Spring aop 异常捕获原理：被拦截的方法需显式抛出异常，并不能经任何处理，这样aop代理才能捕获到方法的异常，才能进行回滚，默认情况下aop只捕获runtimeException的异常
换句话说：service上的事务方法不要自己try catch（或者catch后throw new runtimeExcetpion（）也成）这样程序异常时才能被aop捕获进而回滚。
另外一种方案：
在service层方法的catch语句中增加：TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();语句，手动回滚，这样上层就无需去处理异常（这也是比较推荐的做法）
3、使用场景
事务的场景无处不在。而这种场景一般发生在for循环里面处理一些事情，但又不想被阻断总流程，这个时候要catch的话请一定注意了
4、最后
事务被spring包装得已经隐藏了很多细节，方便了我们的同时，也屏蔽了很多底层实现。因此有时候我们对源码多一些了解，能让我们解决问题的时候更加的顺畅
