Data synchronization brings a new aspect to the functionality of the business application. The major difference between centralized and decentralized systems is the existence of tentative data in decentralized systems. There can be multiple different versions of the same data item in the system.
The master database has the officially correct version of the data. The replicas may have a different, unofficial version of the same data. When a replica transaction (which is based on the unofficial replica version of data) is propagated to the master database, transaction validation errors such as update conflicts may occur in the master. In this kind of situation, transactions need to act in a way that meets the requirements of the business rules of the application.
When a transaction validation error occurs, there are different options for handling the situation:
▪Resolve the error automatically without user intervention. For instance in the case of an update conflict, select the most recent update.
▪Leave the master version of the data intact and save a sufficient amount of information about the conflicted or otherwise erroneous operation to allow error correction through manual user intervention.
The first approach does not require anything special from the data model, because transaction validation errors are automatically resolved as they occur and do not require manual attention.
However, the first approach does not always take into consideration all imaginable transaction validation errors, some of which cannot be resolved automatically. For example, if an order is updated in both the master and the replica databases of an Order Entry system, it is very hard to determine automatically which one of the updates is the correct one. Sometimes, user intervention is required to fix the error.
In order to enable the user to fix the error, a sufficient amount of information about the failed transaction must be made persistent. This information can be stored in a separate error log table or the data model can be designed to accommodate multiple versions of the same data item.