[Date Prev][Date Next]
Re: direct local change when a consumer chains a write to the producer? (Was: openldap-server-2.2.29: multimaster support)
- To: Pierangelo Masarati <email@example.com>
- Subject: Re: direct local change when a consumer chains a write to the producer? (Was: openldap-server-2.2.29: multimaster support)
- From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Date: Mon, 21 Nov 2005 11:13:50 -0800
- Cc: RaphaŽl Ouazana-Sustowski <firstname.lastname@example.org>, OpenLDAP devel list <openldap-devel@OpenLDAP.org>
- In-reply-to: <1132594689.6044.6.camel@ando>
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <20498EEB4C91E6CD7543390E@cadabra-dsl.stanford.edu> <firstname.lastname@example.org> <0F84CCF877D1F094219160DC@cadabra-dsl.stanford.edu> <1132493739.3316.112.camel@ando> <F5A02675FC28DA7864C3438C@cadabra-dsl.stanford.edu> <1132505214.3316.117.camel@ando> <email@example.com> <firstname.lastname@example.org> <email@example.com> <1132590414.3330.4.camel@ando> <firstname.lastname@example.org> <email@example.com> <1132592221.3330.14.camel@ando> <1132594689.6044.6.camel@ando>
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
>Via Dossi, 8 - 27100 Pavia - ITALIA