本人最近在使用spring事务管理的过程中遇到如下异常，导致服务端抛出500给前端，让搞前端的哥们抱怨我心里着实不爽，前前后后折腾了近半个小时才得于解决，今天就做个笔记，以免日后又犯这个错误。好了，错误是这样的：

org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only

后来才发现，我这个问题在ssh或者ssm之类的框架下其实是具有一定的普遍性的。上述异常一般都会出现在下述java伪代码描述的场景中：

在ssh或者ssm等框架集成的项目中，通常service层的事务是由spring代理的。service层的方法发生或抛出异常，则事务会回滚，导致无法提交。通常，我们的项目都会设有全局的异常处理机制，一旦发生异常，会有全局的异常处理机制进行统一处理，所以一般不需要在代码中主动捕获异常。

然而，某些特殊的场景中，比如下面的业务层serviceA具有方法methodA，methodA会调用另一个业务层serviceB的方法methodB。在methodA的实际执行过程中，假如methodB有可能抛出异常，但在methodB无论执行是否正常都不能影响methodA的执行的情况下，通常需要methodA主动捕获这个异常。在methodA主动捕获这个异常的情况下，只要methodA的其他代码不抛出异常，则methodA是不会抛出任何异常的。既然methodA不会抛出异常，道理上讲作用于methodA上的事务是应该可以正常提交的呀，对不对？然而事实上，一旦methodB抛出异常，不管methodA的其他代码是否正确执行，整个事务是无法提交的（说这句话的前提是methodA和methodB上都具有事务，并且都由spring进行统一的事务管理）。

 serviceA.methodA()
       doSomethingA();  
      try {  
             serviceB.methodB{}; //这里面有异常标记为回滚, doSetRollbackOnly(status);  
           catch {  
                //捕获异常转到commit时，由于已经标记为要回滚， 回滚并抛出新异常     
       doSomethingB();  
出现上述异常是因为自己之前没有很好的理解spring事务的机制。 上述的methodA被调用执行时，有两个点是被spring事务代理的。也即serviceA.methodA()和serviceB.methodB()，这两个方法中只要有异常事件将回滚。 上述场景中存在事务嵌套，如果methodA中有异常出现事务会直接回滚，但methodB中有异常只是标记状态为需要回滚，最终在methodA中回滚。 上述场景中methodB有异常事务被标记为回滚，可是被methodA捕获了，也就不回滚了，一直执行到最后commit。在commit时spring会判断回滚标志，若检测到存在回滚标记， 则回滚事务并抛出UnexpectedRollbackException异常。
针对上述事务无法提交的解决办法，本人现在总结了两种处理方法，有路过的看到过的，要是还有什么较好的解决方法，不妨给本人留言，大家共同探讨，一起进步吧！言归正传，本人的总结出的这两种解决方法描述如下：
serviceB.methodB不声明为事务代理。 但是很多时候serviceB.methodB也被其他地方使用，并且是需要事务管理的。这时候可以重写一个方法。但是要注意这个方法中数据的一致性。
和1一样也是重写一个serviceB.methodB方法，但在里面不抛出异常,而是将异常转化为一个布尔值并返回，这个返回的布尔值相当于一个标记methodB是否在执行过程中出现异常的状态值。methodA可以根据这个返回的状态值判断后续代码是否有必要继续执行。这样，也可以避免上述异常的产生。
注：http://blog.csdn.net/nmgrd/article/details/51883405