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

核心提示： 您仍然需要多次到达服务器以更新分发器对象或获取 USN 值，这没有任何性能优势，使用 IBM FileNet P8 实现序列号分发器(10)， 多个分发器不管您使用什么技术来实现代码，重复地更新一个对象会导致高访问率储存库的性能下降， 如果有必要的话，提供客户端实用程序代码，这里指的 &ldqu

您仍然需要多次到达服务器以更新分发器对象或获取 USN 值。这没有任何性能优势。

多个分发器

不管您使用什么技术来实现代码，重复地更新一个对象会导致高访问率储存库的性能下降。这里指的 “高访问率 ” 是以数据库标准为依据的。因此每天执行数千条更新很可能并不构成任何问题。当访问率非常高时，您可能想要使用多个分发器对象，让它们分别负责响应一定范围的值。换句话说，不同分发器实例生成的值在全局环境中仍然是唯一的。

关于 3.x Java API 的特别说明

CE 3.x Java API 没有公开以上使用的 Update Sequence Number。事实上，对大多数操作而言，该 API 通常改变其初衷，转而使用最后写优先策略。这是可行的，但是要使用 3.x Java API 编写出性能出色、功能正常的分发器相当困难。如果您的业务条件允许的话，最佳的选择是将应用程序（部分或全部）迁移到 CE 4.x API。

结束语

本文讨论了用于实现序列号分发器的各种技术。和其他开发一样，编写分发器遇到的困难与业务需求和实现需求有很大的关系。如果某人要求我实现一个漂亮灵活的分发器，那么它应该是这样的：

使用与清单 3 类似的第一次写优先代码。

将该代码放到一个简单的 J2EE servlet 中。通过将它部署到一个 J2EE Web 容器中，我们将享受到 J2EE 基础设施的可伸缩性、故障转移和隔离等优点。

限制 P8 对分发器对象或对象的写访问，从而使一般用户不能绕过 servlet 更新值。

配置拥有 RunAs 角色的 servlet，它具有更新分发器对象所需的 CE 权限。

如果有必要，实现一个机制来验证请求方有权限向分发器请求序列号。这仅在考虑号码浪费的场景中比较有意思。

开始使用 servlet 时乐观地假设仅需访问服务器一次就可以从分发器获取到序列号。换句话说，开始时使用 feelingUnlucky 是错误的。在实践中跟踪它的错误率，如果错误率达到一定比例之后，切换到乐观的方法，它能弥补两次访问服务器带来的开销。定期切换回到乐观的方法，看看有没有发生变化。

如果有必要的话，提供客户端实用程序代码，用于调用 servlet 以获取序列号。