我正在使用 spring 的 ldap 补偿事务管理器。我正在使用DefaultTempEntryRenamingStrategy 。
它通过将实体(因此 dn )重命名为 <original_name>_temp 来进行就地软删除。然后在提交牵引力时，如果成功则实际删除，否则回滚。问题是它无法对所有子树节点递归地执行实际删除。
原因: 当它进行软删除时，它实际上是在修改对象的 dn。并且路径现在已更改。但当它实际上要递归删除叶节点时，它不会使用更新的 Dn，而是使用旧的 Dn。
它正在搜索:剩余名称 *'cn=1157718410FB13@example.com_temp,ou=People,o=122C91C0C62A83,o=Customers'*
但实际上它应该搜索 *'cn=1157718410FB13@example.com_temp,ou=People,o=122C91C0C62A83**_temp**,o=Customers’*
我不确定是否需要进行一些配置才能进行递归删除，否则这是一个错误。欢迎提出任何建议，我还没有探索其他策略，即 DifferentSubtreeTempEntryRenamingStrategy。
最佳答案
这听起来确实像一个错误，但我必须承认我不太知道如何使用 DefaultTempEntryRenamingStrategy 修复它。
我希望它使用 DifferentSubtreeTempEntryRenamingStrategy 按预期工作(无论如何，这实际上是首选策略 - 它不是默认策略的原因是它需要更多工作，特别是您需要确保 LDAP 树中有一个位置可以让该策略放置条目)。
关于java - spring compensating.support.DefaultCompensatingTransactionOperationManager 提交在递归删除时失败，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31972593/