[Date Prev][Date Next]
direct local change when a consumer chains a write to the producer? (Was: openldap-server-2.2.29: multimaster support)
- To: Raphaël Ouazana-Sustowski <firstname.lastname@example.org>
- Subject: direct local change when a consumer chains a write to the producer? (Was: openldap-server-2.2.29: multimaster support)
- From: Pierangelo Masarati <email@example.com>
- Date: Mon, 21 Nov 2005 18:38:09 +0100
- Cc: OpenLDAP devel list <openldap-devel@OpenLDAP.org>
- In-reply-to: <1132592221.3330.14.camel@ando>
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <20498EEB4C91E6CD7543390E@cadabra-dsl.stanford.edu> <email@example.com> <0F84CCF877D1F094219160DC@cadabra-dsl.stanford.edu> <1132493739.3316.112.camel@ando> <F5A02675FC28DA7864C3438C@cadabra-dsl.stanford.edu> <1132505214.3316.117.camel@ando> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <1132590414.3330.4.camel@ando> <email@example.com> <firstname.lastname@example.org> <1132592221.3330.14.camel@ando>
[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