Java 中的 LDAP 事务
我必须为我们的用户管理工具创建批量插入功能。我们使用 spring LDAP 构建了一个小型内部库，对于单用户管理（CRUD）来说一切正常。
我想尝试一次插入数百条记录，如果出现问题则回滚。
有没有办法像数据库中那样在 LDAP 中创建事务？
感谢您的想法。
I have to create a mass insertion feature for our user administration tool. We built a small in-house library using spring LDAP, and everything works fine for single user management (CRUD).
I would like to try to insert hundreds of records at a time and rollback if something goes wrong.
Is there a way to create transactions in LDAP like it exists in Databases ?
Thanks for your ideas.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是@adrianboimvaser 的后续内容。
请注意， Spring LDAP 事务support 不使用 XA 事务，而是使用“逻辑”补偿事务，因此 LDAP 的回滚将是针对 LDAP 的补偿操作。虽然这是对无事务的改进，但请注意，这与“像数据库中存在的那样”的典型事务不同。即不支持事务的 ACID 属性。
例如：如果您要向 LDAP 添加 100 个条目，则每条记录都会被一一添加到 LDAP。如果最后添加失败，则回滚操作将删除事务中先前创建的 99 个条目。但是，如果由于某种原因（例如，网络连接中断到 LDAP，这导致第 100 个条目失败），前 99 个条目实际上无法删除，那么即使您尝试回滚事务，您也会在事务之间出现不一致。数据库和 LDAP。即 LDAP 中将有 99 条记录（因为它们无法删除）在数据库中不存在（因为这些记录从未插入或实际回滚）。
我不确定您的情况如何，但如果您经常对 LDAP 进行大量更新，您可能需要考虑使用实际的数据库来避免事务麻烦并优化性能，因为 LDAP 设计用于快速读取和相对较慢的写入。
This is a followup to @adrianboimvaser.
Just a note that that the Spring LDAP transaction support is not using XA transactions but "Logical" compensating transactions so the rollback of LDAP will be a compensating action against LDAP. While this is an improvement over no transactions be aware that this is not the same as a typical transaction "like it exists in Databases". i.e. The ACID properties of transactions are not supported.
For example: If you are adding 100 entries to LDAP each record will be added one by one to LDAP. If the last add fails then the rollback action will be to remove the previously created 99 entries within the transaction. However, if for some reason (e.g. network connectivity is down to LDAP which is what caused the failure for the 100th entry) the first 99 entries cannot actually be removed then even though you have attempted to rollback the transaction you will have an inconsistency between the database and LDAP. i.e. There will be 99 records in LDAP (because they could not be deleted) which do not exist in the database (because those records were never inserted or were actually rolled back).
I'm not sure what your situation is but if you have frequent large updates to LDAP you may want to consider using an actual database to avoid the transaction headaches as well as to optimize performance since LDAP is designed for fast reads with relatively slower writes.
查看文档： http://static .springsource.org/spring-ldap/docs/1.2.0-rc1/reference/#transactions
Have a look at the documentation: http://static.springsource.org/spring-ldap/docs/1.2.0-rc1/reference/#transactions