What sets solidDB Advanced Replication apart from traditional data replication solutions is its principle of building data synchronization functionality inside the application. The following sections describe some considerations in the functionality of the client application.
Providing a tentative data status on the user interface
The tentative nature of replica data means that a transaction that is committed in a replica database can be changed in the master database. Sometimes this has visible implications to the application itself. For instance in an order-entry system, the status of an order can first be Tentatively OK, which means that it has been accepted by the replica database, but not yet by the master database. In your application design, consider whether you want to show the tentative status to the user.
Providing a user interface to manage synchronization
In a stand-alone replica database, the data contents of the database can vary. Data can be downloaded to and deleted from the local database based on the user need. For instance, a salesman might need customer information for the western region today and the same data about the eastern region tomorrow. To be able to dynamically populate the replica database, a user interface might be needed for refreshing new (and existing) data as well as deleting unnecessary local data by dropping the corresponding subscriptions.
Managing the synchronization process
The synchronization process of solidDB Advanced Replication architecture needs to be implemented at the application level. The synchronization process management might contain the following tasks:
▪ Define the contents of the synchronization process, that is, define which transactions are propagated to the master and which publications are refreshed to the replica in a single synchronization message.
▪ Execute the process, that is, send the request message and get the reply message back. Depending on the application need, these steps can be executed as one "synchronous" or two "asynchronous" operations.
▪ Monitor the status of the process.
▪ Resolve the system- and application-level errors that might have occurred during synchronization.
You can design these tasks through the user interface or by an automatic process. For example, you can implement a user interface into your application for manual monitoring and execution of these tasks. Alternatively, you might want to fully automate the tasks inside your application so that no user interaction is necessary.
During synchronization, errors can occur. These errors can be either at the application or at the system level.
▪ Application-level errors
These are errors that occur when the validation logic of a transaction detects an error and manual actions are necessary to fix the situation. For example, if an "insert order" transaction of an order-entry application detects that the customer credit limit has been exceeded in the master database, manual approval to the order is required. Tracking and resolving the errors typically requires an application-level error log table that can be viewed from the client application.
▪ System-level errors
These errors are typically failures in the store-and-forward messaging. For instance, the network might be down when synchronization is being attempted. Due to this, it is important, that proper error handling is implemented in the execution of the synchronization process. The information that is required to monitor and manage the synchronization process is available in the system tables of solidDB.
Providing Intelligent Transaction based on application needs
solidDB Intelligent Transaction is an extension to the traditional transaction model. It allows developers to implement transactions that are capable of validating themselves in the current database and adapting their contents (if required) according to the rules of the transaction.
Users create transactions in replica databases. These transactions are tentative since they have yet to be committed to the master database, which contains the "official" version of data. The replica transactions are saved for later propagation to the master database. In this model, transactions are long-lived and there can be multiple instances of a data item in different databases of the system.
When a replica transaction is propagated to the master database, transaction validation errors such as update conflicts can occur. Transactions must respond in such a way that meets the business rules required for the application. This is the best way for ensuring database consistency and reliability.
Developers need to evaluate the business rules required and build transactions based on the Advanced Replication model. See Implementing Intelligent Transactions for details on creating transactions with solidDB Intelligent Transaction.