This is a follow up to @adrianboimvaser.
Just note that Spring's LDAP transaction support does not use XA transactions, but “logical” offsetting transactions, so LDAP rollback will be a compensatory action against LDAP. Although this is an improvement because no transactions know that it is not the same as a typical transaction “as it exists in the Databases”. those. ACID transaction properties are not supported.
Note that although the same logical transaction is used, it is not a JTA XA transaction; No, two-phase commit is performed, and thus commit and rollback may have unexpected results.
For example: if you add 100 entries to LDAP, each entry will be added one after another in LDAP. If the last addition fails, the rollback will result in the deletion of 99 previously created records in the transaction. However, if for some reason (for example, the network connection does not comply with LDAP, which caused a failure for the 100th record), the first 99 records cannot be deleted actually, although even if you tried to cancel the transaction, you will have inconsistency between the databases data and LDAP. those. there will be 99 entries in LDAP (since they cannot be deleted) that are not in the database (since these entries were never inserted or actually rolled back).
I'm not sure what your situation is, but if you have frequent big updates for LDAP, you might want to use the actual database to avoid the headaches of transactions, as well as to optimize performance, since LDAP is designed to read fast with relatively slow writes.