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

核心提示： 粗略一看，这好像使用了两次服务器循环，使用 IBM FileNet P8 实现序列号分发器(9)，和前面的合作锁代码一样，第一个计数器更新确实是这样，USN 的递增是不受我们控制的，除了某人请求新的序列号之外，我们必须从服务器获取当前的计数器值，但在成功更新之后将保存计数器的状态

粗略一看，这好像使用了两次服务器循环，和前面的合作锁代码一样。第一个计数器更新确实是这样。我们必须从服务器获取当前的计数器值，但在成功更新之后将保存计数器的状态。如果没有其他人同时更新分发器对象，我们随后的更新仅需一次循环。另一方面，如果两个应用程序轮流更新分发器对象，保留的计数器状态就导致不好的结果。对于这种情况，通常需要 3 次循环才能执行一次更新（首次更新尝试失败；获取当前的计数器值；最后成功更新）。即使同时进行更新的应用程序之间有大量时间，额外的开销都是不可避免的（例如，A 在一小时后获得计数器的值，B 在半小时后获取计数器的值）。是否发生额外的开销取决于独立的读应用程序的数量和它们之间的重叠等。布尔参数 feelingUnlucky 控制该方法是否需要两次循环才能更新，或者在一次或三次循环间进行博弈。

其他考虑事项

下面是关于实现和部署的其他注意事项。

使用 USN 取代属性

既然储存库中的每个独立的可持久化对象都有一个递增的 Update Sequence Number，为什么不使用 USN 取代计数器值的定制属性？如果您愿意接受一些条件的话，这是可行的。但除了不需要定义计数器属性本身之外，其他工作省不了多少。

USN 的正常递增基数为 1。目前您还不可以对序列号使用其他递增基数。

事实上，CE 对 USN 的递增模式的指定是模糊的。它的正式用法包括将 USN 与 null 进行比较，或在两个 USN 值之间进行比较，以得出它们的小于、等于和大于关系。在未来的 CE 发行版中，以 1 作为递增基数可能会发生改变，尽管递增的行为没有改变。

严格来说，USN 的递增是不受我们控制的。除了某人请求新的序列号之外，CE 服务器还在每次更新持久化对象之后都将 USN 增加 1。