MarkLogic版本：9.0-6.2
我们有一个自定义的REST API，可从STAGING读取文档，然后更新FINAL中的一些文档，然后在STAGING文档上运行xdmp.documentRemoveCollections。
第1步：从STAGING DB开始。阅读文档
第2步：切换到FINAL DB，将更改应用于FINAL DB中的多个文档
第3步：切换到STAGING DB，对在第1步中读取的文档应用xdmp.documentRemoveCollections
我们正在使用xdmp.eval在数据库之间进行切换，但是注意到该服务正在超时，可能是由于在数据库之间进行了切换。 （例如，如果我们删除xdmp.documentRemoveCollections步骤，则该服务不会超时，可能是因为该服务不必从FINAL切换到STAGING）
我们尝试使用统一流，但是行为不一致，可能是因为FINAL中有多个文档更新。
请建议在CUSTOM REST API中是否有任何预防措施，避免在数据库之间来回切换时超时。
谢谢！
答案 0 :(得分：0)
在这种情况下，超时可能是由于在同一事务中对同一文档的读写所致。步骤3不必“切换”数据库，因为它应该已经在同一数据库中，唯一的切换是步骤2。此工作流很容易死锁，而无需特别注意。 步骤2是否需要同步？如果没有，建议将其排队到任务服务器。 1,3是否需要进行同一笔交易？步骤1可能会在读取的文档上保留一个锁-然后步骤3尝试等待该锁释放以进行更新。 尝试将步骤1强制为已读事务，并验证它会一直停留到步骤3。您可以完全隔离它们在子事务中执行“所有”步骤的步骤（分别）。 推荐在eval（带有字符串）上使用invoke-function（或模块）-使用eval（“我通过连接用户输入构建的某些字符串”）很容易获得“从朋友或敌人那里获取” xquery注入”的行为
您是否正在与其他活动同时执行此操作（相同的REST调用或同一数据库中的不同调用）。
利用“查询控制台”查找在什么时间打开了哪些事务。如果您看到“挂起”，则几乎可以肯定会发现有一个未完成的交易。