0

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 中是否需要采取任何预防措施以避免超时,同时在数据库之间来回切换。

提前致谢!

4

1 回答 1

0

在这种情况下超时可能是由于在同一事务中对同一文档的读取和写入。第 3 步不应该“切换”它应该已经在同一个数据库中的数据库,唯一的切换是第 2 步。这个工作流程很容易死锁,无需特别注意。第 2 步是否需要同步?如果不建议将其排队到任务服务器。1,3是否需要在同一个事务中?步骤 1 可能会锁定它读取的文档 - 然后步骤 3 尝试等待该锁释放以便更新。尝试强制第 1 步成为读取事务,并验证它在第 3 步之前一直保持这种状态。您可以完全隔离它们,在子事务中执行所有步骤(单独)。推荐使用调用函数(或模块)而不是 eval(带字符串)——它很容易获得“xquery 注入”

您是否与其他活动同时执行此操作(相同的 REST 调用或同时对同一数据库的不同调用)。

使用“查询控制台”来查找在什么时间打开了哪些交易。如果你看到一个“挂起”,那么几乎可以肯定你会发现一个开放的交易潜伏着。

于 2019-03-18T20:49:06.977 回答