Multi-Way Replication and Conflict Resolution

Then, how are they dealt with and how are conflict issues avoided? There are two ways of resolution to this tricky problem. One is to design the bi-directional or multi-way replication in such a way that there is minimum scope for conflict generation. The second one is to use the Oracle provided pre-built update conflict handlers to resolve the conflicts. Information will be provided next that will examine how they can be used.

Design Considerations

There are many design techniques and considerations which help avoid conflict situations. When multi-site replication exists for a table, one site should be designated as ‘in-charge’ and only that site can insert and update rows during a particular time frame. Another way to handle the issue is to make each site in-charge of a subset of the data. For example, the London site performs transactions on all the rows with region_id of EUROPE, and the Singapore site takes care of all rows with region_id of APAC. The remainder of the rows are handled by the NewYork site. In this way, partial ownership of the table avoids some potential DML conflicts.

Of course, this method may be too restrictive for business and application systems. In such cases, there are some design considerations which may help avoid conflicts.

For instance, to avoid the uniqueness conflicts, a sequence number can be created and combined with the region code or site-code. This composite value can be used as the primary key and it helps to insert rows freely without getting into uniqueness conflicts.  Instead of using a combined key, a different series of values can be viewed for a different site.