So far, our discussion of data synchronization has focused on the "pull" model, in which the replica decides when to "pull" a copy of updated data from the master. However, in many situations, users may prefer a "push" model, where the master determines when to send data to the replicas. For example, in a "push" model, the master can send data as soon as that data is updated, rather than waiting for replicas to request an updated copy.
The difference between "pull" and "push" models is similar to the difference between "polling" and responding to "signals" or "interrupts". In a "pull" model, the replica never knows when new data has arrived at the master, and thus the replica typically "polls" the master at regular intervals, or when reconnecting to the network, or when manually told to do so by the replica's synchronization administrator. In a "push" model, on the other hand, the master knows when new or updated data has arrived, and sends the data to the replicas.
The advantage of the "pull" model is that it tends to semi-randomly distribute requests to the master; this keeps the master from being overloaded with a large number of update requests at once. The "pull" model also works well when replicas are connected to the network only irregularly (for example, if you keep your data on a PDA (Personal Digital Assistant) and only synchronize your PDA occasionally). The advantages of the "push" model are that out-of-date data is updated rapidly and replicas do not have to waste time "polling" for new data when none has arrived.
Although solidDB® does not provide a true "push" capability, solidDB® provides Sync Pull Notify capability, which is similar to, but more flexible than, push synchronization. With the Sync Pull Notify approach, the master notifies the replica that there is updated data, and the replica may then choose whether to download the updated data.
To implement a system based on Sync Pull Notify, the system must meet the following requirements:
▪Updated data must not be "pushed" to replicas until it is committed. Basically, the data should be pushed at the end of the transaction, not during the transaction.
▪The system must be able to detect when data has changed in the master and thus may need to be pushed to the replica(s).
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 ofthe features "START AFTER COMMIT", "Remote Stored Procedures", and "Replica Property Names". These features are described briefly below. More complete descriptions are elsewhere (Replica Property Names are described later in this manual, and Remote Stored Procedures and START AFTER COMMIT are documented in solidDB® SQL Guide).
The Remote Stored Procedure feature is just what it sounds like — a way to call a stored procedure in another database. Specifically, a replica may create a stored procedure, and a master may call that stored procedure. For example, the replica might create a stored procedure that contains a REFRESH command, and the master could then call that procedure, thus causing the replica to request the refresh.
The "START AFTER COMMIT" feature allows a user to specify an action that will be taken when a transaction is committed. For example, if a specific transaction updates information on the master, then the START AFTER COMMIT could tell the master to do a remote procedure call to the replica after the update has been successfully committed.
The combination of START AFTER COMMIT and Remote Stored Procedures allows you to implement Sync Pull Notify. When the master updates some data, the master can notify the subscribers by creating a START AFTER COMMIT that calls a Remote Stored Procedure on each replica; the stored procedure then refreshes to get the updated data.
The next issue is to decide which replicas are notified — in other words, on which replicas do we call the stored procedure when data is updated. To control this, we use the feature "Replica Property Names", described below. (It is also possible to refer to a single replica using its nodename.)
Note The START AFTER COMMIT feature and the Remote Stored Procedures feature are documented in more detail in solidDB® SQL Guide. You may want to read more about those features before you continue reading about Sync Pull Notify.