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

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



[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
empty;

- 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.

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:    pierangelo.masarati@sys-net.it
------------------------------------------