Resynchronization properties for unidirectional ObjectServer Gateways

To specify how unidirectional gateways resynchronize with the ObjectServers, set the resynchronization properties that are in the properties file. Unidirectional ObjectServer Gateways have fewer resynchronization properties than bidirectional ObjectServer Gateways.

Procedure

To configure resynchronization, set the properties that are described in the following table.

Table 1. Resynchronization properties and command line options of unidirectional ObjectServer Gateways
Property name	Command line option	Description
Gate.Resync.Enable `boolean`	-resyncenable `boolean`	Use this property to specify that the gateway uses resynchronization. The default is TRUE.
Gate.Resync.Type `string`	-resynctype `string`	Use this property to specify the how the gateway resynchronizes table data between ObjectServers when the gateway starts or restores a lost connection. The gateway resynchronizes the tables that are defined in the table replication definition file. See the information that follows this table for the values to which you can set this property. The default is NORMAL.
Gate.Resync.LockType `string`	-resynclocktype `string`	Use this property to specify the locking option on the source and destination ObjectServers while resynchronizing events. You have the following options: FULL: The gateway locks both the source and target ObjectServers. PARTIAL: The gateway only locks the destination ObjectServer. NONE: The gateway locks neither the source nor the target ObjectServer. The default is PARTIAL.

You can set the Gate.Resync.Type property to one of the following values:

NORMAL: For each table, the gateway deletes all the data from the slave ObjectServer. Then, the gateway retransfers the full set of tables from the master to the slave. With this type of resynchronization, the master and slave are fully synchronized. However, table rows that are in the slave but not in the master are lost. Additionally, if table rows are in the master and the slave, the copy of the row that is on the master is retained on both the master and the slave. Any prior updates to the row on the slave are lost.
UPDATE: For each table, the gateway builds a cache that contains all rows in the master and slave ObjectServers. Then, the gateway examines the contents of the cache for each table and compares the row data from the master with the row data from the slave. The data is resynchronized as follows:
- Rows in the slave that are also in the master are updated with the data from the master, if the data in the master is different from the slave.
- Rows that are in the master but not in the slave are copied to the slave.
- Rows in the slave that are not in the master are retained.
With this type of resynchronization, no events are lost, but the master and slave ObjectServers might not be fully synchronized.
Note: The alerts.details and alerts.journal rows are only considered for transfer, if the related alerts.status row is transferred by the gateway. If their corresponding alerts.status row did not require transfer, details and journal entries are not synchronized.
TWOWAYUPDATE: This option behaves in the same way as UPDATE. Then, the gateway behaves as follows:
1. The event caches of the master and slave ObjectServers are compared.
2. Any rows that are in the slave but not in the master are written to the master.
After the TWOWAYUPDATE resynchronization is completed, the master and slave contain identical rows.
Note: The alerts.details and alerts.journal rows are only considered for transfer, if the related alerts.status row is transferred by the gateway. If their corresponding alerts.status row did not require transfer, details and journal entries are not synchronized.
MINIMAL: This option behaves in the same way as UPDATE. In addition, events (that is, rows in the alerts.status table) that are in the slave but not in the master are marked for deletion. To mark these events for deletion, the gateway behaves as follows:
1. For each row of the alerts.status table in the slave ObjectServer that is not in the master, the OldRow field is set to 1.
2. The pass_deletes trigger runs on the slave ObjectServer and deletes all rows in which the OldRow field is set to 1.
The benefit of a MINIMAL resynchronization is that the master and slave ObjectServers are fully synchronized but less data is sent during the resynchronization process. MINIMAL resynchronization is less data-intensive because all the rows are not deleted and then recopied, unlike a NORMAL resynchronization.
Note: The alerts.details and alerts.journal rows are only considered for transfer, if the related alerts.status row is transferred by the gateway. If their corresponding alerts.status row did not require transfer, details and journal entries are not synchronized.

What to do next

After you edit the properties file, restart the gateway.