Conflict Types v6.2

The types of conflicts can be summarized as follows:

  • Uniqueness Conflict. A uniqueness conflict occurs when the same value is used for a primary key or unique column in an insert transaction on two or more primary nodes. This is also referred to as an insert/insert conflict.
  • Update Conflict. An update transaction modifies a column value in the same row on two or more primary nodes. For example, an employee address column is updated on primary node A, and another user updates the address column for the same employee on primary node B. The timestamps of when the transactions occur on each node could be different, but both transactions occur in a time interval during which synchronization has not yet occurred. Thus when synchronization does take place, both conflicting transactions are to be applied. This is also referred to as an update/update conflict.
  • Delete Conflict. The row corresponding to an update transaction on the source node is not found on the target node as the row has already been deleted on the target node. This is referred to as an update/delete conflict. Conversely, if there is a delete transaction on the source node and an update transaction for the same row on the target node, this case is referred to as a delete/update conflict. Finally, in the case where the row corresponding to a delete transaction on the source node is not found on the target node as the row has already been deleted on the target node is referred to as a delete/delete conflict.

The following table definition is used to illustrate conflict resolution examples:

CREATE TABLE addrbook (
    id              SERIAL PRIMARY KEY,
    name            VARCHAR(20),
    address         VARCHAR(50)
);

The following table illustrates an example of a uniqueness conflict.

Table 6-1: Uniqueness Conflict

Timestamp t1
Action

Node A: INSERT INTO addrbook (name, address) VALUES ('A', 'ADDR A');

Node A: INSERT INTO addrbook (name, address) VALUES ('B', 'ADDR B');
Primary node A

id = 1, name = 'A', address = 'ADDR A'

id = 2, name = 'B', address = 'ADDR B'
Primary node B
t2

Node B: INSERT INTO addrbook (name, address) VALUES ('C', 'ADDR C');

id = 1, name = 'A', address = 'ADDR A'

id = 2, name = 'B', address = 'ADDR B'
id = 1, name = 'C', address = 'ADDR C'

t3

Synchronization pushes Node A changes to Node BRow change for INSERT tx id = 1 on Node A results in unique key conflict on Node B

id = 1, name = 'C', address = 'ADDR C'

id = 1, name = 'A', address = 'ADDR A'

The following table illustrates an example of an update conflict.

Table 6-2: Update Conflict

Timestamp t0ActionPrimary node A
id = 2, address = 'ADDR B'
Primary node B

id = 2, address = 'ADDR B'
t1Node A: UPDATE addrbook SET address = 'ADDR B1' WHERE id = 2;id = 2, address = 'ADDR B1'id = 2, address = 'ADDR B'
t2Node B: UPDATE addrbook SET address = 'ADDR B2' WHERE id = 2; Synchronization pushes Node A changes to Node Bid = 2, address = 'ADDR B1'id = 2, address = 'ADDR B2'
t3Synchronization pushes Node A changes to Node BCurrent value of address on Node B not equal old value on Node A ('ADDR B2' <> 'ADDR B')

The following table illustrates an example of a delete conflict.

Table 6-3: Delete Conflict

Timestamp t0ActionPrimary node A

id = 2, address = 'ADDR B'
Primary node B

id = 2, address = 'ADDR B'
t1Node A: UPDATE addrbook SET address = 'ADDR B1' WHERE id = 2;id = 2, address = 'ADDR B1'id = 2, address = 'ADDR B'
t2Node B: DELETE FROM addrbook WHERE id = 2;id = 2, address = 'ADDR B1'Row with id = 2 deleted
t3Synchronization pushes Node A changes to Node BThe row with id = 2 is already deleted on target Node B, hence update from Node A fails.