[RFE] Support LDAP transactions (RFC 5805)

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/581

• Created at 2013-02-12 21:04:00 by pspacek
• Assigned to nobody

---

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.

[389-ds-bot]

Comment from pspacek at 2015-03-31 13:02:02

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

[389-ds-bot]

Comment from pspacek at 2015-03-31 13:53:21

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

[389-ds-bot]

Comment from pspacek at 2015-03-31 19:39:30

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

[389-ds-bot]

Comment from jcholast at 2015-03-31 20:01:51

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

[389-ds-bot]

Comment from pspacek at 2015-03-31 20:29:49

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.

[389-ds-bot]

Comment from nkinder (@nkinder) at 2015-03-31 20:58:54

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.

[389-ds-bot]

Comment from pspacek at 2015-04-01 14:09:24

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.

[389-ds-bot]

Comment from lkrispen (@elkris) at 2015-04-07 17:15:36

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

[389-ds-bot]

Comment from pspacek at 2015-04-07 17:51:57

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.)

[389-ds-bot]

Comment from lkrispen (@elkris) at 2015-04-07 19:39:12

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

[389-ds-bot]

Comment from pspacek at 2015-04-16 21:56:29

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.

[389-ds-bot]

Comment from pspacek at 2017-02-11 22:51:27

Metadata Update from @pspacek:

• Issue set to the milestone: 1.3.6 backlog

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-02-13 01:44:40

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

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-02-13 01:44:47

Metadata Update from @Firstyear:

• Custom field reviewstatus adjusted to review
• Issue close_status updated to: None

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-02-15 00:42:32

Metadata Update from @Firstyear:

• Custom field reviewstatus reset

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2017-05-08 22:02:39

Metadata Update from @mreynolds389:

• Issue set to the milestone: 1.4 backlog (was: 1.3.6 backlog)

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2017-10-18 21:31:15

Metadata Update from @mreynolds389:

• Custom field reviewstatus adjusted to None
• Issue tagged with: RFE

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2020-05-20 16:18:17

Metadata Update from @mreynolds389:

• Issue set to the milestone: FUTURE (was: 1.4 backlog)

[mreynolds389]

Closing for now since there no plans to implement this.