事务里面捕获异常_降龙-第21章：控制和事务

开发一个后端接口控制层是如何运作起来的？控制层是怎么被调用的？可以在控制层做事务控制吗？本章就来解答这些问题。​

前面已经实现了控制反转，把依赖关系全部注入到被调用对象上了，同时容器缓存了所有实例对象，当一个请求送达应用服务器时，我们可以配置过滤器或者servlet来拦截请求，然后进行请求的​具体分发。

首先在我们的tomcat容器配置文件web.xml上加一个配置​：

拦截所有请求，然后在具体类里面开始实现请求分发逻辑。

前面的章节中讲到，项目启动的时候会把控制层的接口注解地址、实例对象、方法体缓存起来，现在就可以根据请求把控制类的实例对象找出来，找到具体的类就可以实现反射方法，找不到就抛出异常信息。

获取到反射所需实例对象和方法体后，我们需要解析反射方法体所需要的参数，设置好参数后执行反射，接收反射结果并把结果按照统一的格式返回给接口调用方。期间反射方法结束后如果开启了事务则需要提交事务，如果出现异常则需要回滚事务，并处理异常。

后面的章节我们还会从切面控制事务，在controller层做事务提交尝试就达到了把事务​包在控制层做到严格一致性。其实在Spring​框架中也是是支持把事务配置在控制层的，只是官方不推荐这么做而已。

其实事务控制就是提交事务在什么时候做，好比是一块在传送带上的布，什么时候切一刀，这块切下来的布就可以拿起来卷成一卷​存放起来了。在做增删改的时候事务一定是开启的，切不设置自动提交，这样才支持事务可以在不同时候提交，也就是所谓的切面，我们可以切​在不同的位置做事务控制。

我们有网盘和迅雷下载这种断点续传功能，事务切面就是在一段数据接受完后就切了，​接收到的数据就存起来不动了。事务控制也是类似道理，切面处提交事务，把数据保存起来，释放前面操作的一些表的行锁或者表锁，增加了数据库的吞吐量，后面如果有系统报错则是有很多办法弥补的，例如是并发导致的乐观锁或者唯一性约束错误那就可以用重试机制或者队列机制处理好这些问题，而针对sql语法错误这种只能是先修改代码，再由定时任务修复错误点之后的数据​。

上面的代码中，我们在控制层的请求调度里面最后做一次事务提交，在异常捕获代码里面做一次事务回滚，严格保证了事务会被释放不出现所等待，保证了最后的切面出现异常，最后一段事务肯定能回滚，如果不在中间切事务切面则整个请求的这一段事务都能回滚​。从而确保了​框架的事务控制不出现问题。

本章暂时讲控制层的事务控制，不深入到更细的业务层切面事务​。

讲一下参数解析，我们知道在控制层可以设置方法参数为数组格式，这就要求前端传入的是数组类型的对象，传统的我们用post请求的json格式传，这个完全能支持绝大部分场景了，所以就默认用json格式传参才会解析流里面的参数。​也就是靠这个约定实现了对象或者数组的参数映射到控制层方法体上的参数对象上。

这里为什么要定义po、vo基类的对象映射处理是因为在基类对象里面我们设置了注解校验类，如果不继承基类则校验就不做了，也就是把控制层的注解校验移到实体对象上去做了，这一点应该是简化配置而不失功能实现的。实体校验单独再放一章讲，这里不展开。

​支持在控制层上设置这些基础类的参数类型，这些类型的数据是根据方法体上写的参数名称从前端入参对象上取的。

总结下，在我的mvc框架中控制层方法可以设置不同类型的对象参数，基类参数可以做入参校验，而基础类型对象则会从前端参数取值映射只做非空校验。其中基础类型参数做非空校验的约束是想约束接口开发的规范性，既然定义了基础类型参数就不要再支持空值参数的请求了。

事务方面，在控制层逻辑走完的最后做一次事务提交，保证每个事务段都是完整的。在异常捕获代码里做事务回滚，保证不会有一段事务段是不可控制异常的。