One more use-case:
https://fedorahosted.org/bind-dyndb-ldap/ticket/158

Hmm, we apparently forgot to add other use cases to this ticket too:
- Roll-back on FreeIPA upgrades when something goes wrong in the middle of upgrade
- --test option for FreeIPA upgrade scripts do run the upgrade (to see if it works) and roll-back at the end

Please be so kind and try to estimate scope of this request. List of use cases is still growing. Thank you!

Transactions would also help to make IPA more robust, as we often do more than one operation per command.

This reminds me a crash we had in the past:
FreeIPA command creates a DNS zone in two steps (because it consists of 2 LDAP objects). Unfortunatelly, the intermediate state where one object exists but the other does not is most likely invalid and this invalid state was causing crash in bind-dyndb-ldap.

Sure, it was a bug in bind-dyndb-ldap, but it nicely ilustrares how these 'impossible' states of data can cause problems elsewhere.

The scope is large, and we are in the middle of evaluating different backend database implementations. This would have to come after we finish the backend work, as I expect that a good amount of the work to support transactions would need to be redone.

I'm not sure what you mean with "redone" - maybe we have the same thing in mind :-)

I'm bringing this request up now with a hope that requirements for (eventual) support for LDAP transactions could be taken into account during backend evaluation and backend work so the amount of re-working could be minimized.

I think there are two sides of this, just implementing support for client transactions is one thing, it would be some considerable work, but could be done.
The other side is, what effect would this have on the server as a whole. A single client could by holding a transaction for some time block all other mods.
So, in my opinion, it is the easiest solution for a client, but from a system point of view I'm afraid of the side effects and hesitate to implement it

I understand that concern. My point of view that not implementing it in DS just shifts the problem to dependent components which later leads to multiple implementations of transaction logic in multiple components which is IMHO not a good result.

Big lock over a whole transaction could be an easy way to implement it but AFAIK RFC 5805 does not require it. Transactions could be also implemented in different ways, e.g.:
Client sends Start Transaction Request and DS internally creates an empty "per-transaction modlist". (I'm not saying that modlist is the right structure - it is just a wild example.)
Client requests modifications inside the same transation - these modifications are queued into the internal DS "modlist".
* Client sends End Transaction Request. At this point DS internally applies all the changes accumulated in transaction modlist. It can either succeed if everything was applied or fail if some other operation changed the data and modlist cannot be applied to all entries. In that case the server returns an End Transaction Response with a non-success resultCode.

Maybe I'm missing something but it seems that this approach limits locking only to processing End Transaction Request message which happens under control of DS and client does not have means to prolong it. (Sure, client can do big transactions - that problem cannot be avoided anyway because client can send thousands and modifications to saturate I/O subsystem anyway. It might be desirable to add limit for number of operations in one transaction/size of modlist or so.)

ok, reading the rfc I think it can be done the way you suggest and should avoid longer lockouts

Two more notes:
There were some rumors that OpenLDAP is going to implement read-own-writes behavior but I'm unable to find any note about it.
It is likely that some standards work needs to be done to add transaction begin/end information into SyncRepl.

I wouldn't mind client transactions, but I would worry about write transactions causing delays.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/581

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.