directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Chu <>
Subject Re: [Informational] OpenLDAP Transactions
Date Fri, 04 Feb 2011 08:47:07 GMT
Alex Karasulu wrote:
> Hi there Howard!
> On Thu, Feb 3, 2011 at 9:56 PM, Howard Chu<>  wrote:
>> Alex Karasulu wrote:
>>> FYI
>>> Hurray! Our respected friends at OpenLDAP are completing the
>>> transaction spec. Nice to know of an existing implementation. Here's a
>>> recent thread that started up on it:
>>> Would be interesting to see how their implementation of transactions
>>> combines with syncRepl now in the picture. Specifically, I'm wondering
>>> if replication will trigger on transaction boundaries, rather than on
>>> each change in the transaction. Also wondering how change sequence
>>> numbers will be impacted.
>> I'm wondering too! Many open questions with this spec. Though I'll note,
>> RFC4533 explicitly states (of syncrepl) "This protocol is not intended to be
>> used in applications requiring transactional data consistency." (Section
>> 1.2)
> I was hoping you guys already figured that all out :-).
>> If folks are looking for transactional consistency in replication, we should
>> probably develop a new spec to address that.
> Seems so now, thanks for the heads up.

Syncrepl only promises eventual convergence, so there's really no reasonable 
way to expect transactional consistency from it. Consider a replica operating 
in refreshOnly mode, polling once every few minutes - between refreshes, it's 
out of date anyway. When it pulls down a refresh, it will be receiving entries 
one at a time; they could represent completed multi-entry transactions or not, 
and any client querying the replica will see in-between state during that refresh.

You could conceivably try to make refreshAndPersist transactional - during the 
persist phase, you can send along the transaction controls with the entry 
updates. Since basically the slapd implementation is to queue up all 
operations of the transaction until the final Commit is received, and then 
write all at once, this will impose some noticeable latency between the 
provider and the consumer. The Consumer would then do the same, queuing up all 
the received writes until it also receives the Commit message from the 
provider. So assuming perfect networks and perfect hardware and software, you 
could propagate the transactional state down the line. The changes would 
become visible atomically, but at staggered intervals relative to the 
execution time on the original server. But if any network link is broken, the 
consumer has to catch up again by using a refresh phase, and the transactional 
consistency is lost during that time.

I guess for delta syncrepl, since we record changes in a log and play them 
back in a known order, we could preserve the transactional state as well.

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

View raw message