[Date Prev][Date Next]
Re: lastmod overlay
> 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.
I'm not sure I understand this point. It's clear that
the need to update the lstmod entry will represent a
bottleneck; only, I couldn't see a better way to design it.
Itìs something based on a specific request, but I thought it
might be useful, and I needed neutral OIDs...
> One reason to virtualize this entry is so that the overlay
> could be layered on non-storage backends.
I think it can be layered on any kind of backends right now.
> 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
Sure, but it likely defeats the purpose of having a generic
> 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.
I'm considering this opportunity; I made it into an overlay
because it was easy to implement; of course an overlay requires
to stick with a specific database becuse w don't have yet a
global mech equivalent to an overlay, and I'm not quite comfy
with slapi right now. I've plans for a global overlay-like
mech, though. I also considered the opportunity to place the
lastmod entry in back-monitor, but this would have implied
a dependency between back-monitor and an overlay... too much
stress for so little ;) Anyway I think at some point we need
to develop an infrastructure so that backends and overlays can
interact with back-monitor, e.g. add and update specific entries
under their own subtree (each backend, each database and each
overlay has one). This is more food for thoughts, though.
PS: I'll fix the OIDs later, when I get to a more performing