directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <>
Subject Re: ContextCSN handling
Date Thu, 13 Feb 2014 16:09:34 GMT
On Thu, Feb 13, 2014 at 5:20 PM, Emmanuel L├ęcharny <>wrote:

> Hi guys,
> we have had a long chat with Kiran about the best way to handle the
> contextCSN attribute.
> This attribute is used for replication, as we need to know if one server
> is up to date. The way to do it is to compare the local contextCSN with
> the remote one. The pb is where to store this contextCSN, and how to get
this is also needed to determine what content needs to be sent to a
syncrepl client

> it when doing a search.
> o the contextCSN is associated with the root of a partition, it's
> associated with teh contextEntry (see further for some new ideas about
> where to store teh contextCSN).
> o it contains the newest entryCSN in the partition.
> o it's updated every time an update is done on the partition.
> o it's persisted (ie, when the server is restarted, it's present)
> Now, when one does a search, we have to have this contextCSN attrbute
> present in the contextEntry (assumng the user has requested the
> attribute, of course, as it's operationnal).
> If we update the contextEntry after *each* update, we wil double to time
> for updating an entry. No way...
> The solution is to store this value in memory, and to recompute it when
> the server is started (finding the newest entryCSN of each partition).
> That being said, we still have to inject this attribute in the
> contextEntry when a search is done, which means we have to detect that
> an entry is a context entry. Not easy, and costly.
> There are two ways to do that :
> o assume that the entry's cache always contain the contextEntry, which
> always contains the contextCsn. In this case, we just have to update the
> contextEntry after any modification (all in all, we just update the cache).
> o modify the OperationalAttributeInterceptor to injetc the contextCSN
> when we detect that a fetched entry is the contextEntry. In order to do
> that, we need a quick way to detect the contextEntry. We need to
> propagate the partition's DN into the SearchOperationContext, so that we
> can compare the length of this DN with the length of the fetched entry's
> DN : if they are equal, it's the contextEntry.
> IMO the second approach is a bit more complicated (but I don't know why,
> I thik it's the best approach...)
> yes, but a slight change, instead of searching for the context entry in
the interceptor, the context entry gets updated in the backed if it the
contextCsn is dirty and the search base is the partition's root and then the
search continues.

besides this, the contextCsn will always be maintained in memory and will
be written(if it is changed) during

> thoughts ?
> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny

Kiran Ayyagari

View raw message