Re: [ldapext] Content Synchronization Operation + Transactions

Howard Chu <> Mon, 29 June 2015 12:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 834C31A90CA for <>; Mon, 29 Jun 2015 05:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.789
X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D6Cd410Q_VKc for <>; Mon, 29 Jun 2015 05:23:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CDDF31A90C9 for <>; Mon, 29 Jun 2015 05:23:38 -0700 (PDT)
Received: from [] (localhost []) by (Postfix) with ESMTP id BA24D83EF9; Mon, 29 Jun 2015 08:23:37 -0400 (EDT)
To: Petr Spacek <>,
References: <> <>
From: Howard Chu <>
Message-ID: <>
Date: Mon, 29 Jun 2015 13:23:30 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0 SeaMonkey/2.37a1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [ldapext] Content Synchronization Operation + Transactions
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Jun 2015 12:23:40 -0000

Petr Spacek wrote:
> On 3.6.2015 09:35, Petr Spacek wrote:
>> Hello,
>> it seems to me that LDAP Transactions (RFC 5805) are not perfectly integrated
>> into Content Synchronization Operation (RFC 4533).
>> Mainly the client has no idea what changes were part of single transaction. As
>> a result, client cannot replicate transactions reliably, especially when
>> connection drops in the middle of persist phase of Content Synchronization
>> Operation.
>> Also some clients could use the information where LDAP transaction
>> started/ended for application-level transactions (if the application uses the
>> data in real-time) or possibly some optimizations (if some application-level
>> work needs to be done after each group of updates).
>> I'm going to sketch -00 draft which will attempt to address this, probably by
>> adding new messages to indicate where transaction started and ended.
>> Naturally, this makes sense only for persist phase.
> The 00 version of the draft is now available. I would really appreciate any
> feedback!
> Particularly, I'm not very sure that "transaction identifier" in "End
> Transaction Notification Message" is the best idea.

Assuming a unique transaction identifier per transaction, I see no reason you 
couldn't allow interleaved transactions during persist stage. (Well, you would 
need to send the txnID along with every message, so that may be excessive 
overhead.) In OpenLDAP transactions would not be interleaved at execution time 
anyway so perhaps it's a non-issue.

On a slightly related note, I intend to submit an extension to RFC5805 adding 
a Prepare Transaction request. This would enable 2 phase commit, allowing us 
to support transactions spanning multiple DSAs. With OpenLDAP's back-ldap, 
back-meta, back-relay, and glue, the capability is sorely needed.

   -- Howard Chu
   CTO, Symas Corp. 
   Director, Highland Sun
   Chief Architect, OpenLDAP