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