[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)

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.  Of course,
syncrepl would then need to ignore changes to that
entry that have an later CSN.

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

Of course, the devil is in the details.

I also note that if we were ever to support a floating master
system where adds must be done on the server holding
the parent, one could use such chaining combined with
a "get token" control so as to ensure authority for
the added entry was transferred atomically to the entry's


At 09:38 AM 11/21/2005, Pierangelo Masarati wrote:
>[moved to -devel for discussion]
>On Mon, 2005-11-21 at 17:57 +0100, Pierangelo Masarati wrote:
>> Technically, this could be solved by extending the functionality of the
>> "chain" overlay so that, when configured to chain writes to the producer
>> when a referral to it is returned by the consumer, it directly writes to
>> the consumer after the producer returned success; at the same time (in
>> case of slurpd) the producer should not send the change to the consumer.
>> However, this is dangerous because there might be other intermediate
>> changes to that very same data that didn't make it to the consumer yet.
>> Those changes would then apply in an incorrect order. 
>> Maybe we could use something like this:
>> - the chain overlay attaches a control to the chained write that
>> contains the entryUUID and the entryCSN
>> - the producer processes the write; upon success, if the entryUUID and
>> the entryCSN were the same, it returns a control response value that
>> indicates the consumer can directly apply the write.
>Elaborating a bit more:
>- of course no response would be returned to the client until either the
>local change could be performed and it completed, or the local change
>could not; in that case, the consumer would be misaligned until
>replication takes place regularly.
>- add: the control would be empty; in case the modification can be
>directly performed, the control response would contain the newly
>generated entryUUID, entryCSN and createTimestamp; otherwise it would be
>- modify/modrdn: the control would contain the entryUUID and the
>entryCSN; in case the modification can be directly performed, the
>control response would contain the newly generated entryCSN and
>modifyTimestamp; otherwise it would be empty;
>- delete: the control would contain the entryUUID and the entryCSN; in
>case the modification can be directly performed, the control response
>would contain the newly generated entryCSN; otherwise it would be empty;
>one issue to consider is the potential conflict with syncrepl:
>- the refreshAndPersist mode could be dealt with within the producer,
>which should not propagate the change to the consumer the chained
>request came from;
>- the refreshOnly mode could be dealt with at the consumer side.
>Or, this whole stuff could be annealed into syncrepl.
>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