博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
SpringMVC+Mybatis+事务回滚+异常封装返回
阅读量:4232 次
发布时间:2019-05-26

本文共 2725 字,大约阅读时间需要 9 分钟。

问题的背景:
  1. 使用dubbo搭建分布式服务架构,service的实现,采用SpringMVC4.1.6+MyBatis3.2.8。
  2. 为了少维护一个维度,拟对service接口进行通用性定义,即让业务的变化,不影响已定义的service接口。
最终Service的方法签名定义如下(示例):
public ServiceResult addProduct(ServiceParam param)
其中
ServiceResult定义如下:
public class ServiceResult
{ private T result; /** * 错误返回code */ private int retCode; public int getRetCode() { return retCode; } public void setRetCode(int retCode) { this.retCode = retCode; } public T getResult() { return result; } public void setResult(T result) { this.result = result; }}
其中ServiceParam定义如下:
public class ServiceParam
{ private T param; public T getParam() { return param; } public void setParam(T param) { this.param = param; }}
此方法签名保证远程调用两端的业务变化,不会对此接口造成影响。实现了运维维度减一。
其中,ServiceResult封装了所有的业务和运行异常,将之转化为errorCode返回。如此便减少了异常的远程传输的消耗,同时隔离了调用两端的异常耦合,也避免了调用方在嵌套的异常捕捉块里进行业务处理的尴尬。
但是,在实际的框架搭建中,却发现了这样的一个问题,
addProduct方法的事务,如果通过Spring来管理,则必须要抛异常来进行事务的回滚。如果方法抛了异常(对调用者来说,就是远程异常),则不能满足我们把异常转化到errorCode来输出的目的。
因此,我们必须想办法去把异常捕获转化成errorCode,同时又不能影响事务回滚。经过多次尝试,终于圆满解决该问题。特此记录分享于此。
下面是我的思路及解决办法:
既然使用的是Spring来管理事务,则就用AOP来拦截相关Service方法,在事务回滚过后,继续捕捉到异常,对该异常进行转化输出。
第一步,建立AOP拦截类
@Aspect@Component@Order(0)  public class ExceptionAspect {    /**     * 配置切入点,该方法无方法体,主要为方便同类中其他方法使用此处配置的切入点     */    @Pointcut("execution(* cn.xx.dubbo.security.service..*(..))")    public void aspect() {    }    @Around("aspect()")    public ServiceResult around(JoinPoint joinPoint) {        System.out.println("===============START");        ServiceResult result;        try {            //调用拦截的方法主体            result = (ServiceResult) ((ProceedingJoinPoint) joinPoint).proceed();        } catch (Throwable e) {            System.out.println("出现了异常:" + e.getMessage());            result = new ServiceResult();            result.setResult("exception:" + e.getMessage());            result.setRetCode(-1);        }        System.out.println("===============END");        return result;    }}
在该类中,定义切面执行的顺序Order(0),即最外层。
第二步,使用注解对service服务方法进行事务定义,并在service方法抛出业务异常,以便使得事务回滚。
 
@Override    @Transactional    public ServiceResult addProduct(ServiceParam
param) throws Exception { Product product = param.getParam(); int rlt = biz.addProduct(product); if(rlt == 0) throw new Exception("操作失败!"); else { ServiceResult
result = new ServiceResult(); result.setResult(rlt); return result; } }
第三步,修改Spring配置文件
 <!--使用注解式事务声明,加入order属性,使其大于0,则优先于自定义的AOP类执行事务-->
最后用Junit测试该service方法,即便该方法抛异常,最外层的
ExceptionAspect
 也会拦截到该异常,在事务正确回滚之后,把异常
转化为errorCode,封装到ServiceResult中成功返回,改造成功!

转载地址:http://qjpqi.baihongyu.com/

你可能感兴趣的文章
ZooKeeper(3.4.5) 使用Curator监听事件
查看>>
AtomicBoolean介绍与使用
查看>>
java volatile
查看>>
Curator-Framework开源Zookeeper快速开发框架介绍
查看>>
Zookeeper和Curator-Framework实践系列之: 配置管理
查看>>
JAVA NIO高效处理优化 -- 使用EPoll
查看>>
Netty的高性能及NIO的epoll空轮询bug
查看>>
一起学Netty(一)
查看>>
一起学Netty(二)之 Hello Netty的原型图解
查看>>
一起学Netty(三)之 SimpleChannelInboundHandler
查看>>
一起学Netty(四)之 ChannelHandler,ChannelHandlerContext,ChannelPipeline
查看>>
一起学Netty(五)之 初识ByteBuf和ByteBuf的常用API
查看>>
一起学Netty(六)之 TCP粘包拆包场景
查看>>
一起学Netty(九)之LengthFieldBasedFrameDecoder
查看>>
一起学Netty(十一)之 Netty心跳之IdleStateHandler
查看>>
一起学Netty(十二)之 Netty心跳简单Demo
查看>>
一起学Netty(十八)netty源码学习之netty server端源码初读(上)
查看>>
一起学Netty(二十)netty的比较规范的C/S端的写法
查看>>
一起学Netty(十三)之 Netty简单的重连机制
查看>>
一起学Netty(十四)之 Netty生产级的心跳和重连机制
查看>>