EJB 3 事务传播和 UnboundId LDAP SDK
目前，我使用 EBJ 3，必须制作 bean，它必须执行大型业务操作，包括将数据保存到数据库、发送一些 JMS 消息以及将其他一些数据保存到 LDAP。我必须使这个操作保持ACID，所以这对于将数据持久化到DB或将消息发送到JMS来说不存在任何问题（所有这些操作都支持事务传播）。但目前我坚持将数据持久保存到 LDAP。有什么技术可以解决我的问题吗？我们使用 UnboundId LDAP SDK，即 支持 LDAP 事务，但我假设我无法将此事务传播到我的 bean。那么，在这种情况下最好的解决方案是什么？我应该编写一些 JTA 或 JTS 代码吗？或者有一些简单的解决方案？或者是否有可能解决这个问题 - 我可能需要 LDAP 事务中的 2PC 能力？
Currently I work with EBJ 3 and have to make bean, that have to perform big business operation, that consist of persisting data to DB, sending some JMS messages and persisting some other data to LDAP. I have to make this operation ACID, so this is not any problem about persisting data to DB or sending messages to JMS (all this operation supports transaction propagation). But currently I stuck on persisting data to LDAP. Is there any technique that can solve my problem? We use UnboundId LDAP SDK, that supports LDAP transactins, but I assume, that I can not propagate this transaction to my bean. So, what is the best solution in this case? Should I write some JTA or JTS code? Or there is some simple solution? Or is it even possible to solve this problem - may be I need 2PC ability in LDAP transaction?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
RFC 5805 中描述的标准 LDAP 事务工具不提供任何将外部事件合并为事务一部分的方法（并且支持 LDAP 事务的目录服务器也不是很多——我知道 UnboundID Directory Server 可以，内存服务器作为 UnboundID LDAP SDK 的一部分提供，但我不知道还有其他这样做）。
如果您需要能够以原子方式提交到 LDAP 目录服务器和一种或多种其他类型的存储库，那么没有标准的 LDAP 解决方案可以满足这一要求，因此您将需要一个专有的解决方案，并且可能需要您可以编写自己的代码并在 LDAP 服务器内运行。
The standard LDAP transaction facility as described in RFC 5805 doesn't provide any way to incorporate outside events as part of your transaction (and there are also not very many directory servers that support LDAP transactions -- I know that the UnboundID Directory Server does, and the in-memory server provided as part of the UnboundID LDAP SDK, but I'm not aware of any others that do).
If you need the ability to commit to an LDAP directory server and one or more other kinds of repositories in an atomic manner, then there is no standard LDAP solution that can accommodate that, so you will need a proprietary solution, and it would probably require you to write your own code that would run inside the LDAP server.