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. 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. 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.
thoughts ?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
