directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: We need to implement Transactions in the server
Date Sat, 15 Jan 2011 12:39:00 GMT
On Sat, Jan 15, 2011 at 1:58 PM, Emmanuel Lecharny <> wrote:
> Hi guys,
> after my previous mail on AP handling, here is a second mail about
> Transaction management in ApacheDS.

We need to make a distinction between protocol transactions and local
internal transactions. Let me do this now:

(1) Protocol Transactions

RFC 5805 defines a protocol transaction, where multiple LDAP
operations can be grouped into a single unit, where a single failure
will roll back all changes induced by the operations. We need this too
but first we need local internal transactions as in #2 below.

(2) Local (Internal) Transactions

This is an implementation detail. It's about making sure that each
protocol operation that is issued against the server, (not a set of
protocol operations as in #1), is atomic. Why you say would this not
be atomic? Well some operations actually produce multiple changes, as
pointed out in this email for administrative operations.

First we need Local Transactions #2, then we can easily implement
protocol transactions #1. Once #2 is done #1's implementation just
becomes a matter of keeping a transaction open across a block of
protocol operations and committing once the block completes or on
failure rolling all changes back.

> As LDAP guarantee that every operation made on an entry is ACID, we have a
> problem when such an operation impact more than one entry. This is typically
> the case for AP, if we decide to modify the selected entries immediately,
> but not only.
> A new RFC has been issued ( which expose
> a way to implement transactions, it may be time to think about it for a
> future 2.0-Mx version.

Talked about this RFC above as a spec for protocol transactions.

> In any case, we have to have a solution that guarantees that we can update 2
> entries and have a server in a stable state, even if one of the updates
> fails, or if the server crashes in the middle of the operations.
> In fact, we need two things :
> - external transactions, as described by the RFC
> - internal transactions for our technical reads

Ahh we're speaking the same language here great. I started writing
above before getting to this section.

> (once we have the internal transaction, exposing them to the user should be
> just a matter of adding a control).

Yep, control/ext op whatever the impl detail you're right.

> Note that I don't have the complete fields covered here, it's pretty new to
> me, and this was just a matter of starting a discussion on this matter.
> Thoughts?

Inline. Thanks for kicking off the discussion.

Alex Karasulu
My Blog ::
Apache Directory Server ::
Apache MINA ::
To set up a meeting with me:

View raw message