Re: LCUP and PSearch on Sync-And-Persist

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.


> 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?)

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?

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