Re: ctxcsn.c commit/rewind/graduate_commit_csn

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 04:24 AM 10/16/2004, Howard Chu wrote:
>As I understand it, the pending_csn_list is maintained because we don't guarantee that operations commit in a particular order, and so op CSNs are in fact NOT sequential.

CSN, in LDAPsync, are not commit sequence numbers but change
sequence numbers.  The subtle difference is that changes may
not be committed in the same order in which they were received.

>This seems like a fundamental flaw.

LDAPsync was specifically designed not to require commit
sequence numbers.  In fact, any form of timestamps is good
enough for LDAPsync.

>Since CSNs are assigned early in the processing of an op, we really need a guarantee that write operations complete in the same order that they're received, or at least in the same order of their CSNs, otherwise CSNs are useless for actually describing the order in which to propagate changes.

LDAPsync doesn't require changes be propagated in the commit
order, or in change sequence order.  LDAPsync only requires
the events sent cause eventual convergence.

If one has commit sequence numbers, one can avoid sending
some redundant events.  However, that would (without underlying
DB support for commit sequence numbers) come at the expense
of serializing DIT updates.

In implementing LDAPsync, we decided the expense of a few redundant
events was worth not having to serialize of DIT updates.

Now, if the underlying database were to support true commit
sequence numbers (thinking BDB 4.3), then using them instead
of our entryCSNs would be appropriate.  (That is, entryCSN
could become some virtualization of the BDB4.4 transaction
serial numbers.)

Kurt