Detecting and resolving data conflicts is easy with SymmetricDS Pro 3.0. I'll show you how to detect and fix conflicts manually, then we'll setup a resolver so the newest update wins automatically. The web console with SymmetricDS Pro makes all of this easy to accomplish.

Configuring Synchronization

In some synchronization scenarios, there are multiple clients that can update the same piece of data while syncing to a central server. We'll use a server node and two client nodes to create a conflict. Using the classic 2-tier profile that comes with SymmetricDS Pro, we setup bi-directional sync with the clients pushing data to server and the server waiting for pull from the clients.

On each node, we create a customer table that stores the name and phone number of customers. In the configuration, we setup a Trigger for this table that routes in both directions.

create table customer ( id varchar(50), first_name varchar(50), last_name varchar(50), phone varchar(50), last_updated timestamp, primary key(id) );

To make sure our synchronization is working, we add a piece of data to the table.

insert into customer values ('1024', 'Jane', 'Doe', '614-555-1212', current_timestamp);

 

Configuring Conflict Management

To enable conflict management for this table, we go to the Configure->Conflicts screen. For flexibility, a conflict can be configured at different levels. We can enable conflict detection for all data syncing between two nodes, data within a channel, tables within a catalog/schema, or a specific table. We'll specify conflict detection for the customer table when the client syncs to server. Next, we specify the USE_TIMESTAMP detector to use the last_updated column on our table. If the last_update timestamp when the data is changed at the source is different from the timestamp when the data is loaded at the target, a conflict will be detected. Finally, we specify a MANUAL resolver so we can watch the conflict happen and deal with it then. There are lots of other detectors and resolvers that can be configured, which are described in the documentation. And if you can't find the one you need, you can use the Java API to write a custom one.

 

Performing the Conflict

Now that we're configured to detect and resolve a conflict, it's time to create one. We go to the client1 database and update customer's phone number.

update customer set phone = '614-555-0001' where id = '1024';

Then we go to the client2 database and update the same piece of data.

update customer set phone = '614-555-0002' where id = '1024';

As the clients send their batch data to the server, the conflict is detected. You can see the error in the Outgoing Batch screen on the client or the Incoming Batch screen on the server. The console shows the batch in error and also indicates there is a conflict that needs manual attention.

To manually resolve, we click the batch in error, which pops up a Manual Resolution dialog to let us edit the data. We can see the rows involved in the conflict: the old and new rows from the source where the change occurred, and the existing row in the target database that didn't match what was expected. The resolve row at the bottom is for us to specify what the data should actually end up being. It's pre-filled with the new incoming row, or we can change it to different values. Another option is to checkmark "Resolve by ignoring" which will throw away the incoming row.

After clicking "OK" the batch is resolved with the next client sync. Of course, manually resolving conflicts can become tiresome, which is why you might choose an Automatic Resolver instead. If we head back to the Configure->Conflicts screen, we can change the resolver to be NEWER_WINS, which complements our detector. It will also use the last_updated column to choose the row with the newer timestamp as the winner in a conflict.

Conclusion

The SymmetricDS Pro web console enhances the experience of conflict management in the new version of SymmetricDS Pro 3.0. Manual resolution of conflicts is as easy as clicking on the batch and picking the winning row. The ability to detect and resolve conflicts with a variety of configurations extends the scenarios that you can solve in production.

Eric Long
Author: Eric Long

Eric is a software developer and technology enthusiast with a background in developing custom applications for Information Technology. As a long-time Linux user, he strongly believes in open source. He focuses on product solutions and spreading the word for JumpMind.