Re: Conflict resolution in Multimaster replication(Postgres-R)

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