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

[Howard Chu <hyc@symas.com>]

Michael Ströder wrote:
> Howard Chu wrote:
>   
> > 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.
> >     
>
> When integrating software with a directory you don't have the power to
> insist on using this rather unknown control in the clients. Big software
> vendors are most times refusing such a feature request.
>
>   
> > 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?
> >     
>
> I'd prefer having a replication configuration directive for that.

That would be simplest, but I can see needing this option on a 
per-request basis, as there may be a mix of clients in the same 
environment with different requirements. Assuming most clients don't 
re-read the just-modified entry, you gain throughput by keeping the 
updates asynchronous. For clients that re-read, the update must be fully 
synchronous, and this poses a problem (ITS#3671, losing connectivity to 
a consumer will hang the provider).

For these fairly special cases I can see configuring syncprov to be 
synchronous based on the authcID, that would allow your PKI system and a 
chaining consumer to work correctly. But in a synchronous situation I 
don't see a good fix for the hang issue.

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