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

Re: direct local change when a consumer chains a write to the producer?

Pierangelo Masarati wrote: 
I note that an alternative to copying the result of
the modify to slave, another way to address inconsistent
reads after modify is to chain the read as well.

That is, if a server chains a modify for a client, it
should then chain any subsequent read of that entry
by that client as well. That is, treat this read as
if it included a dontUseCopy control.

Agree; but I fear the issue here is to workaround the behavior of clients
that shouldn't even be aware of contacting a replica, not to mention the
dontUseCopy control; of course, if the client uses that control under the
assumption that it might be contacting a replica, everything __should__ go
smooth.  Or do you mean that the replica should keep track of those
entries it sent a referral on update, and act as if the control was
attached?  This really sounds like going off track.  In this case, I'd
rather prefer chaining the operation and (optionally) syncing.

There's another possible approach - don't return a Modify response to the client until the necessary syncing has occurred. In the old syncprov implementations this was implicit - writes on the provider would not complete until all the persistent consumers were updated, so a consumer that chained a write to a provider could not send a response to the client until the consumer was sync'd. Of course now the persistent consumers are updated asynchronously, so some work would be needed to regain the synchronous behavior.

The question is how important is it that clients be able to immediately follow a write request with a read request, and why these clients aren't just using a post-read control in the first place. If this is something that needs to be done frequently, then we probably need to provide an option somewhere in syncprov to go back to its fully synchronous behavior. Perhaps that should be a control of its own - "WaitForSlaves". Still, only newly written clients would be aware of this control, so what should the default behavior be without it?

--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/