When data is replicated, servers can use one of the following approaches:
▪ Pull: To find out if there is new data, the replica database typically "polls" the master at regular intervals, or when reconnecting to the network, or when manually told to do so by the replica database synchronization administrator. This corresponds to the REFRESH operation in solidDB Advanced Replication. When the replica database refreshes, it requests that the master database send all of the data in a particular publication (or the data that has changed since the last refresh operation).
The advantage of the "pull" model is that it tends to semi-randomly distribute requests to the master database; this keeps the master database from being overloaded with a large number of update requests at the same time. The "pull" model also works well when replica databases are connected to the network only irregularly (for example, if you keep your data on a mobile device and only synchronize your device occasionally).
▪ Push: The master database determines when to send data to the replica databases. For example, the master database can send data as soon as that data is updated, rather than waiting for replica databases to request an updated copy. solidDB servers do not use a true "push" method.
The advantages of the "push" model are that out-of-date data is updated rapidly and replica databases do not have to waste time "polling" for new data when none has arrived.
▪ Hybrid: solidDB uses a hybrid approach called "Sync Pull Notify". In this approach, the replica database is notified that new data is available. The replica database can then "pull" the new data by executing a REFRESH statement. The refresh is optional; after being notified that there is new data, the replica database can choose to refresh immediately, or to refresh after delaying, or simply to ignore the notification and not refresh at all.
To implement a system based on Sync Pull Notify, the system must meet the following requirements:
▪ Replica databases should not be notified about new or updated data until the transaction is committed.
▪ The system must be able to detect when data has changed in the master database and notify replica databases to perform a refresh.
In solidDB Advanced Replication, Sync Pull Notify is not implemented as a feature; instead the Sync Pull Notify capability is implemented by using a combination of the following features:
▪ Remote stored procedures: Remote stored procedures are stored procedures in another database. A replica database can create a stored procedure, and a master can call that stored procedure. For example, the replica database might create a stored procedure that contains a REFRESH statement, and the master could then call that procedure, thus causing the replica to request the refresh. For more information, see Calling remote stored procedures.
▪ START AFTER COMMIT statement: The START AFTER COMMIT statement allows you to specify an action that will be taken when a transaction is committed. For example, if a specific transaction updates information on the master database, then the START AFTER COMMIT statement could instruct the master database to do a remote procedure call to the replica database after the update has been successfully committed. For more information, see START AFTER COMMIT.
▪ Replica property names: Replica property names determine the replicas on which the stored procedure is called when data is updated, see Replica property names.
Note It is also possible to refer to a single replica database by using its server name.
The combination of START AFTER COMMIT and remote stored procedures allows you to implement Sync Pull Notify. When the master database updates some data, the master database can notify the subscribers by creating a START AFTER COMMIT that calls a stored procedure on each replica database; the stored procedure then performs a refresh to get the updated data.