Hello Chen,

that's indeed a problem which is specific of TextDB (TextDB is not really suitable nor intended for productive use). Real DB backends commit when finishing processing a message so this problem does not occur there.

Still, we'll have a look if TextDB can be improved to allow for the kind of suspend & resume testing you are doing, which of course totally make sense.

Lukas

[email protected]

On 23.06.2009, at 05:19, Chen Congwu <[email protected]> wrote:

Hello Lukas

While I was testing SyncEvolution in network failure cases with Synthesis
Server, I found this issue:

If session 1 is interrupted due to client-side network failure, session 2 later retries to sync again before session 1 timesout, the server lost items which session 1 has already sent. Currently I have to change the server side session timeout to 10s and let client side retry session sleep a while forcing server side session timeout to workaround this issue, but this seems not perfect.

The underlying course is: During interrupted session 1, if synthesis receives client side changes and sucessfully processed it, it only makes the server side db change in memeory. The change will not commit until synthesis found this session timesout and start to abort. This will confuse client and causing
inconvenence,there maybe two possible solutions:

1) The server side db commit changes as soon as possible: when synthesis server returns a 2xx acknowledge to client, it should also commit the changes to db at
the same time.
2) The server side may add a mechanism to detect if the same client comes up again. If so, abort the previous interrupted session as soon as possible to
commit changes.

What's your opinion? Note I am using Text DB for demo server, maybe other
DB implementations have different commit policies.

--
Regards,

Chen Congwu
Moblin China Development


_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis

Reply via email to