开发中遇到的并发和数据库问题

• 1并发问题

  • 1.1:一个状态修改引起的问题

  • 1.2:本地和服务器因为同一个状态撕咬后的解决方案

• 2数据库问题

  • 2.1:一个状态修改引起的问题

  • 2.2:安卓能支持Sqlite多线程操作吗

  • 2.3:临时文件的产生与解决

  • 2.4:数据库主键的选择

  • 2.4:为什么要加索引

并发问题

一个状态修改引起的问题

        就是我们本地做了同步和异步两种操作，每个操作都会牵扯到对某个状态的修改，判断，展示。除此之外，在别的快递员也可以在别的机器上对某个订单的同个状态进行修改，这么多的不确定因素导致的结果很多，可能会有意想不到的问题，即便测试也很难把所有的情况都测出来，会导致线上很多问题。
那这个问题该怎么解决？

本地和服务器因为同一个状态撕咬后的解决方案

       并发问题一直都是程序员头疼的问题，一般来说市面上大多数的安卓端app是不存在并发情况的，在我目前负责的项目中有线程池不停的轮询数据库操作，这样就会导致并发。

1. 每个单号的提交进行状态的修改
2. 提交的时候对状态修改
3. 单号与任务号的绑定设置在提交的时候

问题现状：
1、同一库区多个未提交的任务；
2、多个未提交的任务是同一个理货员在同一个PDA建立的；
3、多个未提交的任务是同一个理货员在不同的PDA建立的；
4、多个未提交的任务是同一个部门不同的理货员建立的；
5、多个未提交的任务共同点为未提交且每个任务有部分运单已扫描；

中转业务处理现状：
1、同一库区任务未提交前，任务下拉扫描明细会获取该库区所有的运单号信息，包含已扫、未扫的运单号；
2、运单号详情包含“运单号、重量、体积、状态”
3、同一库区不同任务已扫描的运单CE端需要重传已扫描信息给中转（中转业务要求）

解决方案分析

方案一、不同任务下拉扫描详情时状态为已扫描的运单号理货员不重扫。
有利端：
1、不同任务理货员不需要手动重扫运单状态为已扫描的运单
2、节省了人力：快递体积小、数量多，假如新建任务后需要重扫已扫描的运单，会带来人力的大量消耗
不利端：
1、同一个理货员创建的不同任务，由新建任务时CE端自动同步扫描的运单号信息，会导致扫描时间不一致；
2、不同的理货员创建的不同任务，新建任务时CE端自动同步扫描的运单号信息中理货员工号不一致，会导致理货员工作量无法统计的问题；
3、导致PDA页面显示的已扫描的运单号错乱，理货员不清楚此种运