EAS流程卡死问题的分析处理报告

一、问题背景：

11月4日，EAS发生第一次流程大面积卡死，部分流程卡死无法进行。11月5日重启服务后相关流程正常运转。之后又发生了数次流程大面积卡死现象。

二、分析处理过程：

第一次未引起重视，认为是个案，所以未进行仔细的研究。发生第二次后，发现后台数据库有锁，但锁的语句为传递的参数，未能定位到确定的单据。考虑11月份发生了两个业务，第一个是启用差旅费用报销单，一个是修改了自助餐的汇报关系。开始怀疑为汇报关系导致的。分析由于后台数据库锁为费用报销单，但是汇报关系不仅仅是费用报销单使用，排除。之后分析差旅费用报销单，发现设计的时候使用的是费用报销单的审核功能，首先定位的是这个，但是测试系统未能重现问题，修改后，相关问题未解决。

将问题提交给金蝶后，金蝶分析了相关日志和流程。给出的问题为平台问题，需要打流程补丁。由于这个问题不是一开始就有的，确定金蝶给的方案不是这个问题的针对性方案。所以继续分析该问题。

12月中旬，物业保障中心反馈说每次流程卡死，他们的流程的单据状态都修改不过来。1月8日，物业保障的一个费用报销单卡死。后台产生锁，结束锁后，改流程重新卡死，重新启用该流程，后台重新产生锁。反复多次后，确定后台锁由该流程引起。

分析物业保障中心报销流程，发现11月3日做了更改。分析更改前后的变化，为在部门经理后加入了自动变更单据状态为审批中的环节。咨询FI模块系统管理员，是为了解决单据经过部门经理审批后提单人依然可以修改单据的问题。分析流程发现，流程有一个分支符合条件后会出现更新单据状态为“审批中”紧接着更新状态为“审批通过”。理论上解释了数据库死锁