业务场景
我们现在有一个类似于文件上传的功能，各个子站点接受业务，业务上传文件，各个子站点的文件需要提交到总站点保存，文件是按批次提交到总站点的，也就是说，一个批次下面约有几百个文件。
考虑到白天提交这么多文件会影响到子站点其他系统带宽，我们将分站点的文件提交到总站点这个操作过程独立出来，放到晚上来做，具体时间是晚上7:00到早上7:00。
这个操作过程我们暂且称作“排程”。 排程在运行之后，先获取所有需要上传到总站点的批次信息，拿到批次信息之后，将这个批次表的状态置为正在同步数据，这个时候，如果这个批次再有业务人员上传文件，发现批次正在同步，就会返回操作失败。
现在产生的问题：
1，排程获取到批次，准备将批次表状态置为正在同步，注意这时候批次表还没有改成正在同步。
2，业务人员对这个批次提交100张文件，由于批次表状态还没改成正在同步，所以校验通过，准备插入数据到数据库，注意这时候文件信息还没插入到数据库，只是准备插入。
3，排程将批次表信息置为正在同步，并且获取到批次下面所有文件信息保存到内存，准备一个一个上传文件。
4，业务人员上传的文件信息成功保存到数据库。
这种情况下，就会导致，第四步保存到数据库中的文件信息并没有提交到总站点。
分析：
大家没看懂上面的业务信息，没关系，我们可以以一种更通俗的方式来描述：
我们去电影院看3D电影， 假如电影是在9:00开播， 9:00之后演播大厅关门，然后服务人员给所有坐在位子上的人发一个滤光眼镜，这时候就会有一个问题，那些正在走向位子上的人怎么办？ 这就是我们现在的问题。
我们想到2种解决方案：
1： 我们关上门之后等待一段时间，让所有的人都走到位子上，之后服务人员再发眼镜。
2：服务人员每隔一段时间就检测下，有没有坐在位子上的人没有眼镜，没有眼镜就发一个。
注意：业务场景看电影的人是没办法主动要眼镜的 J
如果使用第二种方法，我们几十个分站点会频繁访问总站点查询数据，这个查询是全表扫描，这对数据库性能影响太大。考虑到这个排程进程是后台进程，第一种方法虽然处理慢点，但是对系统影响更小，而且在一定程度上会减缓服务器的CPU压力，最终我们选择了第一种方案。
希望能对你有帮助。
Java多线程导致的的一个事物性问题,布布扣,bubuko.com
原文：http://blog.csdn.net/zhwwashere/article/details/38589233