Hello Srinivas,
M2Y wrote:
> My basic question is: in multimaster replication, if each site goes
> ahead and does the modifications issued by the transaction and then
> sends the writeset to others in the group, how the ACID properties be
> maintained?
Well, there are different approaches. With regard to locking, you can
differentiate between pessimistic and optimistic locking. Synchronous
replication solutions like two-phase commit and most statement based
solutions do pessimistic locking: upon updating a row - and thus locking
it - they make sure every other node locks the same row as well before
proceeding.
Asynchronous replication solutions (including the original Postgres-R
algorithm just mentioned by Robert Hodges) do optimistic locking: they
proceed with the transaction even if they don't know in advance if the
same rows can be locked for that transaction on all other nodes. They
optimistically assume it will be possible to lock them in most cases. In
all other cases, they abort one of two conflicting transactions.
Here you can distinguish even further between eager and lazy solutions:
a lazy solution defers the check against conflicting transactions on
other nodes to sometime after the commit. Upon detecting such a
conflict, it must thus abort an already committed transaction (late
abort). That's a violation of the ACID properties, but it's worthwhile
in certain cases. On the other hand, the eager solution does the
conflict checking and possible aborting *before* committing, thus
maintaining full ACID properties. That method then suffers from an
increased commit latency, dependent on the network.
See [1] for more information.
> A more general question is: for Transactional isolation level
> 4(serializable level), the information such as locking of rows be
> transmitted across sites? If not, what is the mechanism to address
> concurrency with serializibility.
Depends on the algorithm, but transferring every single lock is
generally considered to be too expensive. Instead, locks are transferred
indirectly by sending statements or changesets or such.
What kind of replication are you interested in?
Regards
Markus Wanner
[1]: Terms and Definitions for Database Replication:
http://www.postgres-r.org/documentation/terms