directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Chu <>
Subject Re: [ApacheDS][Mitosis] Replication data
Date Fri, 07 Dec 2007 17:59:16 GMT
Martin Alderson wrote:
> Howard Chu wrote:
>> As Kurt used to remind me, a CSN is a Change Sequence Number, but it
>> is not a Commit Sequence Number. The order in which you see CSNs
>> isn't necessarily the order in which those changes were committed in
>> the DB. As such, the syncrepl protocol assumes that the changes it
>> receives are in random order.
> I'm not sure I see the difference.  I thought CSN's were used to
> determine the order in which changes occurred.  The changes would need
> to be committed in the same order unless they were totally unrelated.
> In ApacheDS we are currently committing the changes as soon as they are
> received.

Yes, assuming one change was received after the previous one was committed, 
then the order of those two changes would be perfectly sequential. But in a 
multi-threaded environment with many clients submitting unrelated changes, 
there's no guarantee that they get committed to disk in the same order the 
server received them.

>>> Also, if we have the attributes in a child entry of the actual log
>>> entry as I suggested we would need to specify a parent-child
>>> relationship in the search.
>> That sounds like a painful model to implement.
> Painful because there is no way to specify a parent-child relationship
> in an LDAP search, yes.  I could probably flatten it into a single entry
> for each change, though.
> So do you OpenLDAP guys store the changes in LDAP as entries?  If not,
> do you wrap your backend changelog store with an LDAP interface as Alex
> is suggesting?

Yes we store changes as LDAP entries; that's why I keep pointing you guys at 
our Logging schema...

Here it is again
   -- Howard Chu
   Chief Architect, Symas Corp.
   Director, Highland Sun
   Chief Architect, OpenLDAP

View raw message