>
>
>
>b) The Group Communication blob will consist of a number of processes which
>need to talk to all of the others to interrogate them for changes which may
>conflict with the current write that being handled and then issue the
>transaction response. This is basically the two phase commit solution with
>phases moved into the group communication process.
>
>I can see the possibility of using solution b and having less group
>communication processes than databases as attempt to simplify things, but
>this would mean the loss of a number of databases if the machine running the
>group communication process for the set of databases is lost.
>
The group communication system doesn't just run on one system. For
postgres-r using spread
there is actually a spread daemon that runs on each database server. It
has nothing to do with
detecting the conflicts. Its job is to deliver messages in a total
order for writesets or simple order
for commits, aborts, joins, etc.
The detection of conflicts will be done at the database level, by a
backend processes. The basic
concept is "if all databases get the writesets (changes) in the exact
same order, apply them in a
consistent order, avoid conflicts, then one copy serialization is
achieved. (one copy of the database
replicated across all databases in the replica)
I hope that explains the group communication system's responsibility.
Darren
>
