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
http://highlandsun.com/hyc/drafts/draft-chu-ldap-logschema-xx.html
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
