Re: LCUP and PSearch on Sync-And-Persist

Mircea Pana wrote:

> Rich,
>
> > [...]Why can't the clients first do a synchronizeOnly session?
>
> This sounds like a good idea. When it starts, the client will have to perform
> two operations in sequence (SyncOnly followed by SyncAndPersist) instead of just
> one, but it doesn't sound like it would be a significant overload. Thanks for
> the suggestion.
>
> > [...]I'm not sure why the client would receive a reload required assuming the
>
> The cookie may become invalid if the server and/or the application are re-loaded
> from backups for instance.

Right.

> > Why would the application have to compare the old one with the new one?
>
> The application actually compiles the data and sends it over to various service
> engines. In a full resync session the application compares the new data set with
> the old one to determine the old data units to be removed. These correspond to a
> subset of the entries deleted after the last LCUP session but before the current
> one. (I suppose that in case of a "full sync." session, the Directory server
> will not send the previously deleted entries. Right?)

Right.  So a client acting as an intermediary would want to prevent doing a full resync of its clients.

> I still have a question: In case of a SyncOnly session, the server "knows" when
> there is no more data to send to the client and closes the session with a
> SearchResultsDone (with lcupSuccess). Since the Directory server also has this
> state information in case of a SyncAndPersist session, would it be difficult or
> wrong to include a notification in the appropriate EntryUpdateControlValue?

That necessarily means server implementors will have to sort the entries into two groups.  I could forsee that many clients may
not care to know when they are "in sync" in a syncAndPersist session, and the server would just be able to insert updated entries
anywhere it chooses to in the outgoing data stream.  Of course this is highly implementation dependent - I don't think this would
work given the model I spoke of using CSNs for ordering.  Or maybe we can make this behavior switchable by the client.  I'll speak
to the other authors about this.

>
>
> I appreciate your help.
> Thanks a lot,
> Mircea.
>
> >
> > Please know that I am trying to understand your problem, to see if LCUP can
> > solve it right now, that LCUP may be able to solve it
> > with some minor modifications, or that LCUP is simply not suitable for your
> > problem.
> >
> > >
> > >
> > > Any suggestions would be greatly appreciated.
> > >
> > > Thanks,
> > > Mircea.
> > >
> > > >