>
>
>>
>>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.
>
So if we hold WS(C) until we receive commit messages for WS(A) and
WS(B), will that meet
your synchronous expectations, or do all the systems need to commit the
WS in the same order
and at the same exact time.
>
>
>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).
>
Right
>
>Hope this doesn't add too much confusion :-)
>
No, however I guess I need to adjust my slides to include your
definition of synchronous
replication. ;-)
Darren
>