自定义活动(三)
锁定处理
在前面的文章我已经讲过，把用户数据的收集同工作流实例中分离出来。数据的存储也就很可能地进行了分离。这种数据的分离会要求我们去做更多的工作：
l 维护工件（如稿件，任务等要在工作流中进行加工的东西）与工作流实例的关系。我们用WF自带的SqlWorkflowPersistenceService来完成工作流实例的存储。那么工件、工件与WF实例的关系及相关的处理情况应交给应用系统来维护。有关这方面的内容请看后面的“工作流的工件维护框架”。
l 保持工件与WF实例的状态一致性。这部分的解决请后后面的有关“状态一致性”的话题。
l 独占式处理。这是本节的重点内容。
独占式处理，其实处理过程很简单，就是在处理时对数据加把锁，就象进厕所把门锁上一样：）。这里不讲怎样去加锁，而是讲对哪些数据进行加锁以及何时进行加锁。
我们来看一下要完成一个审核活动所要处理的数据
l 对工件进行编辑并进行保存
l 记录工件的审核情况
l 运行完后保存WF实例的状态
其实我们需要锁定的数据只有两个：工件和WF实例。如果工件锁定不成功的话则应退出WF实例的运行，有关如何中止活动的运行，就看后续的文章；如果加锁成功则直到WF实例持久化后再解锁。注意，虽然WF的SqlWorkflowPersistenceService本身有加锁的功能，但还是要等到WF实例持久化后再对工件解锁。
这里有一件事情还要说明。工件在审核过程中可能不会被修改，如果从打开工件时刻开始加锁，则会大大的增加占有时间！切记。我们可以在工件第一次被修改的事件中进行加锁处理，以尽可能地减少占有时间。
讲到这里，细心的人可能发现，工件可能在处理过程中没有被修改，即没有产生加锁信息，此时如果我们运行了WF实例，情况是危险的。我们在进行WF时一定要检测工件是否被锁定了，如果没有锁定则进行加锁，然后再运行WF实例。
先讲到这里，可能有些人嫌我写的太少了，我只能说对不起了，我还有很多的工作要做。待续。