2019年遇坑

一、关于JPA的坑

1、open-in-view   默认true开启

OpenEntityManagerInViewInterceptor

在不使用OpenEntityManagerInViewInterceptor的情况下，Controller层或View层访问FetchType.LAZY(延时加载)属性将会抛出异常，解决该问题有以下其它三种方法：
(1)、将FetchType.LAZY(延时加载)属性配置为FetchType.EAGER(即时加载)属性，但这将导致严重的性能问题
(2)、使用Hibernate.initialize(proxy)在Service层强制加载需要使用的属性，由于一般情况下对象需要加载的属性并不是固定的(可能A功能需要加载X属性而B功能又需要加载Y属性...)，这将导致Service层需要根据不同的功能编写不同的方法，从而Service层的复用性和灵活性将大大降低，同时也会大大增加代码量
(3)、使用DTO，该方法同样存在复用性和灵活性差的问题，同时代码量也会成倍的增加(大量DTO<>PO的转换)，由于存在大量对象之间的拷贝，也会存在一定的性能下降

在使用OpenEntityManagerInViewInterceptor的情况下，Controller层或View层访问FetchType.LAZY(延时加载)属性可以很好的执行，但又会存在以下几个问题：
(1)、在Controller层查找到的实体对象依然为托管状态，对该实体对象的修改有可能会更新到数据库(查找该实体对象后拥有可写事务Service方法的情况)，这将导致修改实体对象与数据库的同步的不确定性
(2)、Controller层、View层、Service层将共享一级缓存，这将导致查找到的实体对象可能已被其它方法修改
(3)、Session生命周期延长，这将导致数据库连接的占用时间也被延长，对性能会有一定的影响

在使用open-in-view:true后，遇到两个坑
1、查询到实体对象后，对该对象进行修改后，再在提交事务时，对象的修改会提交到数据库（需要修改对象时，为保证不提交到数据库，最好将这个对象拷贝到另一对象）；
2、一个请求从Controller层进来，最后返回后，在这个线程结束后事务才提交，数据库连接才释放，影响了性能，在并发量大的时候会报获取不到数据库连接；

资料：
1、https://blog.csdn.net/qq_38658642/article/details/90729827

思考：
1、在使用open-in-view:false后,会不会有其他问题出现？

二、关于在并发、交易型系统修改数据库状态问题

1、尽量减少数据库操作，例如一条流水在一笔交易中尽量只insert加update一次或者select加update一次；
2、在修改流水状态时，一定要加上where条件（防止多次修改，导致修改为异常状态）；

三、关于异步、线程池

1、在确定交易结果后，应立即返回或通知下游，其余记账、风控应异步完成，提高并发；
2、使用线程池异步处理问题时，当异步线程池队列已满的时候拒绝策略应该是不再处理这种异步请求（直接丢弃）并且告警；

四、关于JmsTemplate往MQ发送消息问题

1、每次向MQ发送请求时，使用连接池获取连接创建Session（PooledConnectionFactory 连接池）

思考：
1、使用同一个Session甚至同一个Producer,当MQ的failover模式中的一台MQ挂了之后会不会有什么影响？
2、使用以上方法和使用连接池在性能上的问题？