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

核心提示： 假设分发器对象进行无获取实例化（即通过 Factory.CustomObject.getInstance() 方法），该技术则导致需要再次回到 CE 服务器，使用 IBM FileNet P8 实现序列号分发器(6)，以应用锁并获取当前的属性值，如果该对象已经锁定，订阅和事件处理对系统定义的事件

假设分发器对象进行无获取实例化（即通过 Factory.CustomObject.getInstance() 方法），该技术则导致需要再次回到 CE 服务器，以应用锁并获取当前的属性值。如果该对象已经锁定，就不能获得当前值，所以我们将多次遍历分发器对象以等待锁定的机会。此外，还需要再次回到 CE 服务器以储存新的计数器值。该技术导致的性能开销还是合理的，锁定/解锁特性的总体使用也是合理的。

在该用例中使用 P8 合作锁的主要问题是它仅是合作锁。在仅出现该锁的情况下，CE 服务器将不阻止任何更改。您可能会乐观地假设所以应用程序都使用合作锁。但是在现实中，您可能不能阻止应用程序 bug 绕过锁。这种场景不难想像，某人编写了一段使用分发器对象的独立代码，但忘记了使用锁。

使用事件处理程序

这可能有些无关紧要，但如果您阅读了上一小节对合作锁的讨论就会发现，要可靠地获得一个序列号必须至少两次回到服务器。能不能通过一次返回就解决问题呢？要实现这个想法，我们必须至少将一部分计算转移到 CE 服务器上。能够实现该目的的 CE 机制就是事件处理程序。下面是想法论证：

无获取实例化分发器对象（没有循环）。

我们需要对分发器对象进行某些更改，使它能够触发事件。CE 有一个允许您定制事件的特性。事实上，这个类称为 CustomEvent。作为实现该目的的一次性设置的一部分，我们定义一个新的定制事件，并将其持久化在保存分发器对象的 ObjectStore 中。

定制事件不会作为其他事件的副作用启动，而是在某人调用可订阅对象上的 raiseEvent() 方法时被触发。在服务器上，订阅和事件处理对系统定义的事件是一样的。在分发器对象上调用 raiseEvent()，然后通过刷新调用 save()（获得 WjcCounter 的当前值）。