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中是否有任何预防措施可以避免超时，同时在数据库之间来回切换。
提前致谢！
在这种情况下超时可能是由于在同一事务中读取和写入同一文档。第3步不应该'切换'它应该已经在同一个数据库中的数据库，唯一的转换是第2步。这个工作流很容易死锁而不需要特别注意。步骤2是否需要同步？如果不建议将它排队到任务服务器。是否需要1,3在同一笔交易中？第1步可能会对其读取的文档进行锁定 - 然后第3步尝试等待该锁定释放以便更新。尝试强制执行步骤1作为读取事务并验证它是否一直保持到第3步。您可以完全隔离它们在子事务中执行所有步骤（单独）。建议使用eval上的调用函数（或模块）（带字符串） - 使用eval（“我通过连接用户输入构建的一些字符串”）很容易获得'xquery注入'行为（来自朋友或敌人）
您是否与其他活动同时执行此操作（同一个REST调用或同一个DB同时执行不同的调用）。
利用“查询控制台”查找在什么时间打开的事务。如果你看到“挂起”，那几乎可以肯定你会发现一个潜伏的开放交易。