Mybatis 多拦截器执行顺序报错及解决方法

        之前使用 Mybatis 的拦截器插件做 sql 重写,忽然发现重写后的 sql 没有被真正地执行,之前没有遇到这样的事情,后面怀疑是当前这个模块的 PageHelper 库影响了插件的执行,然后新建一个模块加入 PageHelper 库,果然验证了猜测。

        因为 Mybatis 的 Executor 接口有两个 query() 方法,一个有 BoundSql 参数,一个没有。

public interface Executor { 

  <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler,
      CacheKey cacheKey, BoundSql boundSql) throws SQLException;

  <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler)
      throws SQLException;
}

在实际执行的 CachingExecutor 中,它会调用 4 参数的 query(),并在这个 4 参数的 query() 方法中调用 6 参数的 query() 方法。

public class CachingExecutor implements Executor {
  public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds,     ResultHandler resultHandler)
      throws SQLException {
    BoundSql boundSql = ms.getBoundSql(parameterObject);
    CacheKey key = createCacheKey(ms, parameterObject, rowBounds, boundSql);
    return query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
  }

  @Override
  public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler,
      CacheKey key, BoundSql boundSql) throws SQLException {
    Cache cache = ms.getCache();
    if (cache != null) {
      flushCacheIfRequired(ms);
      if (ms.isUseCache() && resultHandler == null) {
        ensureNoOutParams(ms, boundSql);
        @SuppressWarnings("unchecked")
        List<E> list = (List<E>) tcm.getObject(cache, key);
        if (list == null) {
          list = delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
          tcm.putObject(cache, key, list); // issue #578 and #116
        }
        return list;
      }
    }
    return delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
  }
}

        debug 发现有 PageHelper 库的代码实际执行的是 6 参数的 query() 方法,而一般情况下是执行 4参数的 query() 方法,而且我们也是期望执行 4 参数的 query() 方法。 

        根据 Mybatis 多拦截器的执行顺序规则,拦截器链越靠后的插件越先被执行。因为如果拦截器链表的元素先后顺序如果是A->B->C,那么会先生成A的代理,该代理结果再代理B,该结果再代理C,那么执行顺序肯定是先执行C的代理逻辑,再执行B的代理逻辑,再执行A的代理逻辑。Mybatis 的插件模式利用了动态代理确实很强大。

public class InterceptorChain {

  private final List<Interceptor> interceptors = new ArrayList<>();

  public Object pluginAll(Object target) {
    for (Interceptor interceptor : interceptors) {
      target = interceptor.plugin(target);
    }
    return target;
  }
}
public interface Interceptor {

  Object intercept(Invocation invocation) throws Throwable;

  default Object plugin(Object target) {
    return Plugin.wrap(target, this);
  }
}
public class Plugin implements InvocationHandler {

  private final Object target;
  private final Interceptor interceptor;
  private final Map<Class<?>, Set<Method>> signatureMap;

  private Plugin(Object target, Interceptor interceptor, Map<Class<?>, Set<Method>> signatureMap) {
    this.target = target;
    this.interceptor = interceptor;
    this.signatureMap = signatureMap;
  }

  public static Object wrap(Object target, Interceptor interceptor) {
    Map<Class<?>, Set<Method>> signatureMap = getSignatureMap(interceptor);
    Class<?> type = target.getClass();
    Class<?>[] interfaces = getAllInterfaces(type, signatureMap);
    if (interfaces.length > 0) {
      return Proxy.newProxyInstance(type.getClassLoader(), interfaces, new Plugin(target, interceptor, signatureMap));
    }
    return target;
  }
  @Override
  public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    try {
      Set<Method> methods = signatureMap.get(method.getDeclaringClass());
      if (methods != null && methods.contains(method)) {
        return interceptor.intercept(new Invocation(target, method, args));
      }
      return method.invoke(target, args);
    } catch (Exception e) {
      throw ExceptionUtil.unwrapThrowable(e);
    }
  }
}

而我们的插件再拦截器链中是第一个元素,PageHelper 的 PageInterceptor 插件是第二个元素,所以我们执行了自己的插件后会进入到 6 参数的 query() 方法,结果发现 BoundSql 还是原来的,导致新 sql 没有被执行。

如果进入了 PageHelper 的拦截逻辑但不分页的话会执行

//rowBounds用参数值,不使用分页插件处理时,仍然支持默认的内存分页
resultList = executor.query(ms, parameter, rowBounds, resultHandler, cacheKey, boundSql);

但 executor 是一个代理,它的下一步执行会先进入插件的代理逻辑才会进入这个 6 参数的 query() 方法。

解决方法:

1,让我们的插件位于拦截器链的最后一个位置,这个可以通过 Spring 启动的扩展规则实现,监听容器刷新事件,每监听到一次就去 Configuration的拦截器链表里查看是否有我们写的插件,没有就加到链表末尾,有就把它删除,并添加到链表末尾;使用 @PostConstruct 或 afterPropertiesSet() 钩子方法则不一定保证它一定位于最末尾。

2,参照 PageHelper 的规则修改代码,https://github.com/pagehelper/Mybatis-PageHelper/blob/master/wikis/zh/Interceptor.md

 获取到 BoundSql 后,继而获取到原始 sql,重写原始 sql,最后对其进行赋值即可解决。

BoundSql newBoundSql = new BoundSql(ms.getConfiguration(), sql,
                parameterMappings, boundSql.getParameterObject());
if (args.length == 6){
    args[5]=newBoundSql;
}

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值