[Date Prev][Date Next]
Re: direct local change when a consumer chains a write to the producer?
- Subject: Re: direct local change when a consumer chains a write to the producer?
- From: Howard Chu <firstname.lastname@example.org>
- Date: Mon, 05 Dec 2005 02:06:13 -0800
- Cc: OpenLDAP devel list <openldap-devel@OpenLDAP.org>
- In-reply-to: <email@example.com>
- References: <firstname.lastname@example.org> <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> <firstname.lastname@example.org> <1133163684.3318.10.camel@ando> <438AC745.email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051203 SeaMonkey/1.5a
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/