#581 [RFE] Support LDAP transactions (RFC 5805)
Opened 7 years ago by pspacek. Modified 3 months ago

For IPA it would be handy to use LDAP transactions as defined in RFC 5805.

If I read Trac and 389 web correctly, there is some internal support for transactions but I didn't see transactions between supportedExtensions.

This RFE comes from IPA ticket #3415.

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.

Metadata Update from @pspacek:
- Issue set to the milestone: 1.3.6 backlog

3 years ago

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

Metadata Update from @firstyear:
- Custom field reviewstatus adjusted to review
- Issue close_status updated to: None

3 years ago

Metadata Update from @firstyear:
- Custom field reviewstatus reset

3 years ago

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.4 backlog (was: 1.3.6 backlog)

3 years ago

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to None
- Issue tagged with: RFE

2 years ago

Metadata Update from @mreynolds:
- Issue set to the milestone: FUTURE (was: 1.4 backlog)

3 months ago

Login to comment on this ticket.