directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: ContextCSN handling
Date Thu, 13 Feb 2014 15:28:55 GMT
Le 2/13/14 4:13 PM, Howard Chu a écrit :
> 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
>> 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...)
>
> In OpenLDAP we cache the value in memory by default. 

Yes, this is what we are going to do too : using a VolatileRef to store
the reference to this contextCSN, and update it on the fly.
> There is a  configurable syncprov-checkpoint so after T time or N
> updates we do an actual write of the attribute into the underlying entry.
I'm not sure we need to do taht at all : when the server starts, it's
good enough to look for the newest entryCSN anyway, and it as to be done.


> We also have a flag on the backends indicating whether or not it
> previously had a clean shutdown; if this flag indicates an unclean
> shutdown then we can do a search for the highest entryCSN in the DB.
> (This flag is somewhat obsolete now with back-mdb.)
>
> Aside from that, we of course write the attribute on clean shutdowns.
I wonder if it's necessary. The gain is minimal, you pay the price of
writing the element every T times or N updates, for a server whch is not
supposed to stop, compared to a simpe search on an indexed EntryCSN
attribute at startup...


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com 


Mime
View raw message