[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: direct local change when a consumer chains a write to the producer? (Was: openldap-server-2.2.29: multimaster support)

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


Ing. Pierangelo Masarati
Responsabile Open Solution

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it