记录工作中遇到的bug及解决方案

今天在工作中遇到一个有关锁的问题，解决了比较久的时间，特此记录一下。
背景：车联网项目，app操作车机进行车辆控制，比如通过按钮控制开启天窗，开启闪灯，开启鸣笛等等，数据流是这样的

红色箭头标识流程1，黑色箭头标识流程2。普遍遇到的情况是流程1要比流程2要快。因为前端发出闪灯请求后就立马开始轮询，速度比请求到达车机再从车机异步回调更快。

遇到的问题是：

1.ios同学的轮询请求普遍能获取到车辆异步回调的数据；安卓同学的轮询请求仅仅有很少的请求可以获取到异步回调数据，大多数请求会一直轮询，直到超时。
2.发现数据库接收到车机回调的数据后无法成功落库，只有一个字段被修改，但不知被谁修改。

解决过程：

1.发现ios的首次请求与轮询请求之间间隔了1s，但安卓是首次请求之后立即发起轮询请求。
2.后端提供的轮询接口中，还进行了数据库的更新操作，将每次轮询的结果更新到数据库中（bug）。

最终发现：

安卓请求车控后不等待立刻轮询，此时车机基本上还没有返回回调信息：（前端轮询）先查到旧的数据，（车机回调）数据库更新了数据，（还是前端轮询）又把旧的数据更新到库中

ios请求车控后等待一秒轮询，此时车机基本上已经返回回调信息:（车机回调）更新了数据，（前端轮询）查到新的数据，再更新数据库。

解决方案:

1.轮询时是否可以不进行数据库操作？（可以）
2.数据库加乐观锁。
同学A查了数据库的某一行数据，version为1；
同学B更新了这行数据，version设置为2；
同学A再次更新时的sql条件为： where version = 1 ，此时是无法更新的，这样就可以看出数据被别人动过了。再做处理