数据库连接的释放得看 Model 与 DbPro 中的代码，在那里面全是用的 finally 块来释放，与拦截器没有关系

如果在拦截器中释放，那么你无法阻止别的拦截器得到异常以后不再抛出，那么就无法避免资源泄漏

因此，connection 资源的释放应该越早越好，早释放除了可以避免可能的资源泄漏，还可以提升 connection 的利用效率，在极高并发的时候，很可能是有线程在等待连接池中的空闲连接的

@JFinal 明白。设计上应该从原子处考虑，拦截器只是一个高层上的应用，具体的逻辑还得依靠底层，此是相应的是 model 等处的逻辑实现。否则可能拦截器要释放一遍，到时再出一个高层上的应用，可能又要再释放一遍之类的操作。
以上只是我的个人设计上的主观猜测。

@JFinal 不过有一点还是想不明白。在源码中也看不出根据。
就是在使用 Tx 注解的时候，我的想法是只需要在 controller 层使用就可以了。然后拦截器发现这是一个被事务注解的方法，method.invoke 前调用 setAutoCommit 为 false,再调用本方法的逻辑，然后 commit.在 catch 和 finally 做相应的处理。
那么问题来了，为什么 需要对 service 层的方法做事务增强呢？

@linuxea 这个只能去“单步调试”去了解

@JFinal 乔丹哭泣脸:/