Asynchronous data refreshes can consume large amounts of memory and inflict disk I/O overhead. To avoid this, you can use a synchronous, messageless advanced replication interface. In this mode, the associated data is sent as a data stream, thus conserving memory. This mode also reduces the needed disk I/O bandwidth, because no messages are written to disk.
Tip: You can also restrict the resources available for the refresh operations by using the ReplicaRefreshLoad parameter.
You can define the mode how the replica table is being locked in conjunction with the asynchronous data refresh. The options are:
▪The OPTIMISTIC mode (the default value) defines that the concurrency control method depends on the table type and the isolation level. For D-tables in the OPTIMISTIC mode, the REFRESH will always succeed. For M-tables in general, and for D-tables in the PESSIMISTIC mode, row-level locking will be used. If a lock cannot be obtained, PESSIMISTIC fails and returns an error.
▪PESSIMISTIC defines that the table is exclusively locked, regardless of the table type and isolation level chosen, for the time of refresh. If the lock cannot be obtained, the refresh request fails and returns an error.
By default, all data of a publication REFRESH is written to the replica database in a single transaction. If the reply to the REFRESH request contains REFRESHes of large publications, the size of the REFRESH’s commit block, that is, the number of rows that are committed in one transaction, can be defined using the COMMITBLOCK property.
Setting the maximum size of the commitblock can improve performance of the replica databases. However, data integrity cannot be guaranteed if the data is transmitted in more than one transaction and active users on the replica are changing data at the same time. Therefore, we recommend that you disconnect all online users from the replica database when you use the COMMITBLOCK option.
The TIMEOUT property defines how long the replica server will wait for the reply message. If TIMEOUT is not defined, then FOREVER is used.
See below for an example of a synchronous refresh:
Synchronous refresh
REFRESH my_table; COMMITBLOBK 1000; COMMIT WORK;
For more information about the synchronous refresh syntax, see the REFRESH command in “solidDB® SQL Syntax” in the solidDB® SQL Guide.