Xpages 管理自定义文档锁定以防止文档冲突

Xpages 管理自定义文档锁定以防止文档冲突,xpages,ssjs,Xpages,Ssjs,我在ssjs对象中内置了一个自定义文档过程。在读取模式下单击文档中的编辑按钮时,我调用在后端文档中设置锁定日期/时间和锁定所有者的方法,然后返回true。然后,可以使用ChangeDocumentMode简单操作将文档更改为编辑模式。但是,第一次保存文档时(例如使用简单操作),它会创建一个冲突文档。很可能前端文档在进入编辑模式之前没有意识到后端文档的修改和保存 如果我更改此过程,让我的文档锁定代码设置两个后端文档字段,然后使用context.redirectToPage,则文档将打开到编辑模式,

我在ssjs对象中内置了一个自定义文档过程。在读取模式下单击文档中的编辑按钮时,我调用在后端文档中设置锁定日期/时间和锁定所有者的方法,然后返回true。然后,可以使用ChangeDocumentMode简单操作将文档更改为编辑模式。但是,第一次保存文档时(例如使用简单操作),它会创建一个冲突文档。很可能前端文档在进入编辑模式之前没有意识到后端文档的修改和保存

如果我更改此过程,让我的文档锁定代码设置两个后端文档字段,然后使用context.redirectToPage,则文档将打开到编辑模式,并且从ui保存它不会创建任何冲突文档。但是,如果在使用我的代码解锁文档后,我使用“打开页面”简单操作转到“上一页”退出文档,它只会返回到读取模式,而不是实际关闭文档。我确信,最初的重新定向Topage扰乱了历史,并导致了这个问题

问题:是否有人建议我如何在进入编辑模式前锁定文档、进入编辑模式、保存文档而不引起冲突,以及如何使用“打开页面”简单操作(解锁文档后)退出文档

以下是用于锁定的相关代码示例,包括进入编辑模式的代码:

thisDoc.replaceItemValue("LockOwner",context.getUser().getCommonName());
thisDoc.replaceItemValue("LockDate",session.createDateTime(@Now()));
thisDoc.save();
var url = view.getPageName()+"?action=editDocument&documentId="+thisDoc.getNoteID();
context.redirectToPage(url);

这取决于您的用例。如果您的应用程序是用户访问文档的方式,我建议不要将任何内容写入文档以进行锁定-您只需要为解锁前断开连接(网络、关闭浏览器、崩溃)的用户提供解锁管理功能。 锁定的方式(例如在WebDAV中)是服务器内存中的时间锁定,调用每30秒更新一次。您可以使用经典的Ajax调用来实现这一点

openNTF WebDAV for Domino项目具有这种锁定机制的服务器端,您可能希望从那里复制它

如果您必须写入文档:在readmode下更改序列并在queryOpen事件中更新文档-这涵盖了用户也将编辑URL添加到书签的情况


让我们知道进展如何

使用本机锁定技术(数据库属性和
Document.lock()
)谢谢,Frantisek,但这是我们很久以前考虑的第一件事,但是内置的文档锁定存在一些问题,使得它不适合这种情况。如果我没记错的话,主要的问题是您有一个主锁服务器,并且不是所有的用户(分布广泛)都可以访问该服务器(因为位置问题)。可能还有其他原因,但我现在记不起来了。在分布式环境中锁定可能会很麻烦,通过将标志保存到文档中进行锁定只会使情况变得更糟——事实上,不同的用户可能会独立锁定其版本,这会导致保存冲突。重新考虑您的方案-要么设置全局“锁定”服务器,要么使用各自的本地锁定服务器将文档划分为组。在任何情况下,都需要使锁立即对所有人可见。Domino的内置功能在锁定的文档上存储基本相同的两个标志(用户名和日期/时间)。它只负责管理过程。不过,我的方式还是有点麻烦,你说得对。我将不得不重新考虑doc lock db的想法,看看我过去选择不使用该方法是否有原因。我完全忘记了两件事:1)首先,我应该提到这些是web应用,2)内置的文档锁定功能在web应用上不起作用。我会更新我原来的帖子。你好,斯蒂芬,谢谢。My doc lock对象包括一种机制,用于在用户长时间不活动或异常退出时超时锁定。也就是说,我没有考虑QueryPendDocument(对于XPages)事件。这可能是最简单的解决方案。我将看看服务器内存的想法,看看我以前是否考虑过这一点。它听起来确实类似于使用applicationScope或类似工具,这在复制中不起作用。但我会检查的。谢谢