使用 IBM FileNet P8 实现序列号分发器

核心提示： save() 将触发 CustomEvent， 作为一次性设置的一部分，使用 IBM FileNet P8 实现序列号分发器(7)，在 WjcDispenser 实例或类上提供一个订阅到特定类型的 CustomEvent 的事件处理程序，事件处理程序将为 WjcCounter 属性计算和保存新值

save() 将触发 CustomEvent。

作为一次性设置的一部分，在 WjcDispenser 实例或类上提供一个订阅到特定类型的 CustomEvent 的事件处理程序。事件处理程序将为 WjcCounter 属性计算和保存新值。因此属性不能在同步事件处理程序中进行更新，所以我们将把事件处理程序更改为异步的（在订阅中指定同步或异步）。

客户端应用程序知道事件处理程序如何更新 WjcCounter，因此它执行相同的计算以预测 WjcCounter 的新值。

在这段想法论证过程中，您认为对分发器对象的更新在每个时间点只能发生一次，不管有多少个独立的客户端应用程序正在请求更新。CE 服务器没有 “优化” 中间（冗余）更新。记住，异步事件处理程序的执行是有保证的。事实上，您可能还了解到异步事件处理程序是通过队列进行处理的（这是正确的）。所有这些结合起来似乎能够在每次循环经过 CE 服务器时都能够对 WjcCounter 进行一次可靠的、可预测的更新。

您可能从上文的描述基调中猜到这里存在其他一些问题。事实上，这里存在两个问题。首先，在更新 ObjectStore 中的分发器对象和执行异步事件处理程序之间存在一段很短的时间。如果多个独立的客户端刚好在这段时间内同时进行更新，它们将看到相同的 WjcCounter 刷新值并计算出相同的更新值。即使您能够克服这个问题，并将特定的客户端 save() 活动绑定到事件处理程序的特定触发器中，您仍然还需要解决另一个问题。第二个问题是，尽管异步事件处理程序是通过队列进行处理的，但一个队列有多个读取程序。因此，不能够保证异步事件处理程序的执行顺序与触发更新的顺序一样。

第一个写优先

CE 服务器有一个能够可靠地检测交叉更新的内置特性。CE 实现一个称为第一个写优先 的策略。这意味着如果两个请求同时更新相同的对象，那么第一个请求将成功，第二个请求将失败。对于失败的更新，服务器将抛出一个 EngineRuntimeException，它带有 E_OBJECT_MODIFIED 的 ExceptionCode。附带的异常消息为 “The object ... has been modified since it was retrieved.”。但是，这是什么意思？