Hello Patrick,
a server session can end at any time simply by the fact that the client does
not answer any more within the timeout. But the next session (trying to resume)
can start long before the previous one actually HAS timed out.
So that's why the necessary state required to resume the sync in a subsequent
session is always stored at every message exchange (engRequestEnded()). In a
big installation, the server instance handling the resume might not even be the
same machine - but it will be able to resume from the saved state without any
inter-server session tracking mechanisms etc.
Yes, it costs a bit extra disk IO.
Best Regards,
Lukas
On Mar 4, 2010, at 17:05 , Patrick Ohly wrote:
> I just added blob support to SyncEvolution and noticed that it was
> called for a "PIStored" blob also during a normal sync. That blob holds
> a partial item.
>
> What surprised me was that the data was stored even though the session
> never suspended:
>
> #14 0x000000000082e574 in sysync::TLocalEngineDS::engRequestEnded
> (this=0x1311600)
> at /home/pohly/syncevolution/libsynthesis/src/sysync/localengineds.cpp:5975
> 5975 engSaveSuspendState(false); // only if not already aborted
> (gdb) list
> 5970 // Note: It is ESSENTIAL not to save the state until sync set is
> ready, because saving state will
> 5971 // cause DB access, and DB access is not permitted while sync set
> is possibly still loading
> 5972 // (possibly in a separate thread!). So dssta_syncmodestable (as in
> <=3.0.0.2) is NOT enough here!
> 5973 if (testState(dssta_syncsetready)) {
> 5974 // make sure all unsent items are marked for resume
> 5975 engSaveSuspendState(false); // only if not already aborted
> 5976 }
>
> Why is that done? Is it to be prepared in case that the engine crashes
> or doesn't get a chance to write out its state?
>
> I suppose it doesn't hurt, except for some additional disk IO. Just
> wondering...
>
> --
> Best Regards, Patrick Ohly
>
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
>
>
>
> _______________________________________________
> os-libsynthesis mailing list
> [email protected]
> http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Lukas Zeller ([email protected])
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
[email protected], http://www.synthesis.ch
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
