使用 IBM FileNet P8 实现序列号分发器
2009-12-09 00:00:00 来源:WEB开发网 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鐐劤缂嶅﹪寮婚悢鍏尖拻閻庨潧澹婂Σ顔剧磼閻愵剙鍔ょ紓宥咃躬瀵鎮㈤崗灏栨嫽闁诲酣娼ф竟濠偽i鍓х<闁诡垎鍐f寖闂佺娅曢幑鍥灳閺冨牆绀冩い蹇庣娴滈箖鏌ㄥ┑鍡欏嚬缂併劎绮妵鍕箳鐎n亞浠鹃梺闈涙搐鐎氫即鐛崶顒夋晬婵絾瀵ч幑鍥蓟閻斿摜鐟归柛顭戝枛椤牆顪冮妶搴′簼缂侇喗鎸搁悾鐑藉础閻愬秵妫冮崺鈧い鎺戝瀹撲礁鈹戦悩鎻掝伀缁惧彞绮欓弻娑氫沪閹规劕顥濋梺閫炲苯澧伴柟铏崌閿濈偛鈹戠€n€晠鏌嶆潪鎷屽厡闁汇倕鎳愮槐鎾存媴閸撴彃鍓卞銈嗗灦閻熲晛鐣烽妷褉鍋撻敐搴℃灍闁绘挻娲橀妵鍕箛闂堟稐绨肩紓浣藉煐濮樸劎妲愰幘璇茬闁冲搫鍊婚ˇ鏉库攽椤旂》宸ユい顓炲槻閻g兘骞掗幋鏃€鐎婚梺瑙勬儗閸樺€熲叺婵犵數濮烽弫鍛婃叏椤撱垹纾婚柟鍓х帛閳锋垶銇勯幒鍡椾壕缂備礁顦遍弫濠氱嵁閸℃稒鍊烽柛婵嗗椤旀劕鈹戦悜鍥╃У闁告挻鐟︽穱濠囨嚃閳哄啰锛滈梺褰掑亰閸欏骸鈻撳⿰鍫熺厸閻忕偟纭堕崑鎾诲箛娴e憡鍊梺纭呭亹鐞涖儵鍩€椤掑啫鐨洪柡浣圭墪閳规垿鎮欓弶鎴犱桓闂佸湱枪閹芥粎鍒掗弮鍫熷仺缂佸顕抽敃鍌涚厱闁哄洢鍔岄悘鐘绘煕閹般劌浜惧┑锛勫亼閸婃牠宕濋敃鈧…鍧楀焵椤掍胶绠剧€光偓婵犱線鍋楀┑顔硷龚濞咃絿妲愰幒鎳崇喓鎷犻懠鑸垫毐闂傚倷鑳舵灙婵炲鍏樺顐ゆ嫚瀹割喖娈ㄦ繝鐢靛У绾板秹寮查幓鎺濈唵閻犺櫣灏ㄥ銉р偓瑙勬尭濡繂顫忛搹鍦<婵☆垰鎼~宥囩磽娴i鍔嶉柟绋垮暱閻g兘骞嬮敃鈧粻濠氭偣閸パ冪骇鐎规挸绉撮—鍐Χ閸℃ê闉嶇紓浣割儐閸ㄥ墎绮嬪澶嬪€锋い鎺嶇瀵灝鈹戦埥鍡楃仯闁告鍕洸濡わ絽鍟崐鍨叏濡厧浜鹃悗姘炬嫹

您仍然需要多次到达服务器以更新分发器对象或获取 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 以获取序列号。
更多精彩
赞助商链接