Hello Srinivas,
M2Y wrote:
> Markus: It looks like the hybrid approach used by Postgres-R(as
> described in that paper) is good.
Well, yeah. That's why am working on it ;-)
You are very welcome to download the patch and dig into the sources. See
www.postgres-r.org for more information.
To answer your original question in more details:
> Suppose there are two sites in the group, lets say, A and B and are
> managing a database D. Two transactions TA and TB started in sites A
> and B respectively, at nearly same time, wanted to update same row of
> a table in the database. As, no locking structures and other
> concurrency handling structures are replicated each will go ahead and
> do the modifications in their corresponding databases and sends the
> writeset.
Correct so far. Note that both transactions might have applied changes,
but they have not committed, yet.
In eager mode we rely on the Group Communication System to deliver these
two changesets [1] in the same order on both nodes. Let's say both
receive TA's changeset first, then TB's.
The backend which processed TA on node A can commit, because its changes
don't conflict with anything else. The changeset of TB is forwarded to a
helper backend, which tries to apply its changes. But the helper backend
detects the conflict against TA and aborts (because it knows TA takes
precedence on all other nodes as well).
On node B, the backend which processed TB has to wait with its commit,
because another changeset, namely TA's came in first. For that changeset
a helper backend is started as well, which applies the changes of TA.
During application of changes, that helper backend detects a conflict
against the (yet uncommitted) changes of TB. As it knows its transaction TA takes precedence over TB (on all other
nodesas well), it tells TB
to abort and continues applying its own changes.
I hope that was an understandable explanation.
Regards
Markus Wanner
[1]: In the original Postgres-R paper, these are called writesets. But
in my implementation, I've altered its meaning somewhat. Because of that
(and because I admittedly like "changeset" better), I've decided to call
them changesets now...
