Lotus notes 并发用户在同一时间获得同一文档的句柄

Notes数据库上出现了一个罕见的生产问题。我们的系统在提交期间为请求文档分配一个ID（实时保存然后提交）。发生的情况是，有时两个文档似乎具有相同的ID，但事实并非如此

ID的格式为YYYY-MM-XXX，其中YYYY是当前年份，MM是数字中的月份，XXX是从001开始的数字，然后是之后的数字。分配id时，系统会在视图中检查相同月份的文档所在的位置。如果它没有看到文档，则在ID中指定001，否则，它将获取视图中的最新文档，获取编号，然后将其递增1。然后，新号码将被分配为ID

---

我如何确保在此过程中，我可以根据上述标准分配唯一的id？这个错误非常罕见，我们无法再次模拟它。谢谢你的帮助

一些代码可能有助于了解问题所在，但听起来两个提交文档的用户在同时查看视图时存在竞争条件

在查看视图、获取最新文档、将其递增1、将其存储在文档上、保存该文档、然后更新视图的逻辑过程中，需要花费大量时间，以便下次检查视图时，最新文档的编号更高。你真正需要的是一种包装，这样它才能同步发生。说起来容易做起来难

---

我建议使用@公式，它（我相信）保证是唯一的，代替ID的XXX部分。如果您使用XXX部分进行排序，也许您仍然可以将序列号保存在文档中的某个位置，在最坏的情况下，您将有两个具有相同排序键的文档，这可能适合您的需要。

根据@Ken Pespisa的回答，@Unique更有可能为您提供独特的价值，但这并不是真正的保证。如果两个名字相似的用户（即，相同的首字母、相同的姓氏前两个字母和相同的姓氏最后一个字母）在完全相同的时间（根据系统时钟）在两台不同的客户端计算机上执行@Unique，则仍然可能发生冲突。概率很低，但不是零

---

在Andre Guirard的文章中可以找到关于为Notes文档分配unqiue顺序ID的最终讨论。在我看来，最好的技术是推迟分配唯一的顺序id，并允许在服务器上运行的代理创建id。这提供了唯一性的真正保证（只要您正确编码）。折衷的办法是id不能立即使用。

您可以使用NotesDocument对象的锁定方法在更新文档中的编号之前先锁定文档。如果另一个用户进来，脚本将需要等待锁被释放。释放锁后，下一个用户可以将其锁定以进行更新。

重复的ID文档是否同时提交？数据库是否仅在一台服务器上，而不作为本地副本使用？我见过很多使用unique to the same计算的ID。可能它与我在Evaluate:Evaluate（“@Unique”）中的用法有关，但我不得不放弃它，使用自编码算法。我个人还没有看到过这一点，但在写这个答案时，我突然想到了这一点。我也找不到任何东西可以保证它是独一无二的，这意味着它可能无法保证。也许你自己滚动是最安全的：）