Re: lastmod overlay

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

A couple of thoughts (mostly food for thought)...

This will obviously cause a serialization of directory
updates within the context and contention on the lastmod
entry.  I think it would be offer a version which didn't
back the lastmod entry into the database.  One could even
address persistency issues by determining the values from
the entries at start up, instead of relying on the backing.
If we had ordering indexing, determination would be quick.

One reason to virtualize this entry is so that the overlay
could be layered on non-storage backends.

An alternative (storage DB-based) implementation would be to
simply have a key in a database which stores the ID of the
last modified entry.  This would obviously cause serialization
of updates as well as contention on this index, but at least
you wouldn't have to maintain a whole separate entry when only
an ID is needed.  Then, on read/compare of the entry, one
would look up the ID, fetch the entry referred to, and then
dynamically construct the lastmod entry in order to complete the
operation.

Another alterative implementation be an overlay which sent
a copy of the operation to the monitor backend and have the
monitor backend construct an entry based upon that operation
for monitoring purposes.

Kurt

At 12:00 PM 4/10/2004, Pierangelo Masarati wrote:
>I've committed an overlay that adds an entry rooted at the suffix of the
>database the overlay is staked on.  The entry contains the DN of the last
>modified entry, with the modifyTimestamp, the modifiersName and the type
>of modification.  Needs work yet (support of exops, ...).
>
>Hope it be useful.
>
>p.
>
>-- 
>Pierangelo Masarati
>mailto:pierangelo.masarati@sys-net.it