darren@up.hrcoxmail.com wrote:
>
> >
> >
> > Darren, can you clarify this? Why does it send that message? How does
> > it allow commits not to wait for ordered writesets?
> >
>
> There are two channels. One for total order writesets
> (changes to the DB). The other is simple order for
> aborts, commits, joins (systems joining the replica), etc.
> The simple channel is necessary, because we don't want to
> wait for total ordered changes to get an abort message and
> so forth. In some cases you might get an abort or a commit
> message before you get the writeset it refers to.
>
> Lets say we have systems A, B and C. Each one has some
> changes and sends a writeset to the group communication
> system (GSC). The total order dictates WS(A), WS(B), and
> WS(C) and the writes sets are recieved in that order at
> each system. Now C gets WS(A) no conflict, gets WS(B) no
> conflict, and receives WS(C). Now C can commit WS(C) even
> before the commit messages C(A) or C(B), because there is no
> conflict.
And that is IMHO not synchronous. C does not have to wait for A and B to
finish the same tasks. If now at this very moment two new transactions
query system A and system C (assuming A has not yet committed WS(C)
while C has), they will get different data back (thanks to non-blocking
reads). I think this is pretty asynchronous.
It doesn't lead to inconsistencies, because the transaction on A cannot
do something that is in conflict with the changes made by WS(C), since
it's WS(A)2 will come back after WS(C) arrived at A and thus WS(C)
arriving at A will cause WS(A)2 to rollback (WS used synonymous to Xact
in this context).
>
> Hope that helps,
>
> Darren
Hope this doesn't add too much confusion :-)
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #