Re: LCUP and PSearch on Sync-And-Persist

Mircea Pana wrote:

> > So, if you lose a connection, or the server crashes, or any number of
> > reasons to lose a session, you have to resync from scratch
> > every time?
>
> I have two kinds of client apps.:
>
> 1. A lightweight client without persistent storage resync "from scratch" every
> time. Due to the relatively heavy data processing required, it will wait for
> "sync" state to be reached before compiling the initial data. Subsequently it
> will act on change. Such client has a limited scope (expects to receive a
> moderate number of entries).
>
> 2. A full featured client with persistent storage keeps a copy of the processed
> data (not 1:1 with the raw LDAP entries). Once past the "(re)sync." phase, it
> compiles the data received and takes the necessary actions. It can "recover" a
> broken session based on the cookie of the last successfully processed data
> element.
>
> If the Directory server does not provide an "in sync." indication, the client
> apps. mentioned above need to treat all responses incrementally which would
> affect their performance. So, IMO, even though not a must, supporting such
> feature is a strong wish.

Why can't the clients first do a synchronizeOnly session?  If the server is not under a heavy update load, this will get the
clients sufficiently close.  If the server is under a heavy update load, the clients may have to wait indefinitely to be "in
sync".

> However, there is a case that I don't see how to resolve without an "in sync."
> indication from the server:
> Let's say that an application with persistent storage has received, processed
> and stored a fair amount of data from the Directory server when the session
> closes and the cookie is either lost or corrupted or the client receives a
> "reload required". The only option the client has is to start the next session
> "from scratch". The "old" data can not be cleared away immediately because that
> may lead to temporary disruption of critical services - unacceptable! So, the
> application would attempt to "sync." from the Directory server, process the new
> data, compare it with the old one and apply the delta before going into the
> "persistence" mode.

Why can't the client first do a synchronizeOnly session?  If that session completes successfully, the client knows that it is
"reasonably" close to being "in sync" with the server (depending on the server update load).

If the client loses the cookie, perhaps the server could "guess" about the state of the client if the client still knows some
information like the last update time of the last entry received.

I'm not sure why the client would receive a reload required assuming the client does not lose the cookie, the server is not
reloaded, and the client can "keep up" with the updates on the server.

Why would the application have to compare the old one with the new one?  Why couldn't it just use the new one directly, unless
this is an implementation detail?

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