On Mon, 2005-11-21 at 11:13 -0800, Kurt D. Zeilenga wrote: > In theory, the slave could attach a post-readEntry control to > chaining operation wrapping the the modify request and use > the returned entry to "pre-sync" the value.
We'd need a pre-read to fetch the pre-modify current CSN and entryUUID, in order to understand if the modification can be directly applied to the local database, and a post-read to fetch the newly assigned CSN and modifyTimestamp (and entryUUID, in case of add), to build up the local modification (we already know the modifiersName). > Of course, > syncrepl would then need to ignore changes to that > entry that have an later CSN. I think this implicit in syncrepl, because as soon as this independent operation syncs the CSN, syncrepl should understand it doesn't need to process it futher. Although I didn't consider the issue deep enough yet, there shouldn't be any chance of an intermixing modification, since we are performing it only if the CSN of the original and of the shadow copy were the same, and we get the new CSN after the modification directly from the producer, so there cannot be any change in between. The only issue I see is if (but, how?) another change gets to the producer right after, and sync takes place before the local modification is performed. But this wouldn't yet be an issue, because if the local modification fails, eventually syncrepl will line-up the shadow entry, so we plainly need to ignore failures in the local modification. > > Note that use with a chaining operation is necessary here > for two reasons: > 1) to avoid conflict with any client provided read > entry control, and > 2) appropriate authorization (e.g., as slave not > client). Well, the modification should be chained to the consumer as the client, so that appropriate access control takes place; the local modification should be performed as the replicator identity. So I agree with point (1), but not with point (2), because if the consumer is a shadow of the producer, we should be able to assume that whoever should be able to write to the consumer should also be able to write to the producer. Of course, we might not be able to rebind as the client (unless simple bind was used), so we'd rather need to assert its identity (I guess this is part of the devil you mentioned :). In any case the operation needs to be chained. What's the status of operation chaining? Where should I start looking at? p. Ing. Pierangelo Masarati Responsabile Open Solution SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: [EMAIL PROTECTED] ------------------------------------------
