Bidirectional gateway properties

In addition to the generic ObjectServer Gateway properties, bidirectional gateways have specific properties.

Table 1. Properties and command-line options used by bidirectional gateways
Property name	Command-line option	Description
Gate.ObjectServerA.Buffersize `integer` Gate.ObjectServerB.Buffersize `integer`	-objectserverabufsize `integer` -objectserverbbufsize `integer`	Use these properties to specify the maximum number of entries that the gateway stores in the buffer for this ObjectServer before flushing, if buffering is enabled. The gateway flushes the buffer when the end of a batch of SQL statements has been reached regardless of the buffer size. This property can be used to fine-tune the efficiency of the gateway. The default is 25.
Gate.ObjectServerA.CommonNames `string` Gate.ObjectServerB.CommonNames `string`	-objectserveracommonnames `string` -objectserverbcommonnames `string`	If the gateway is connecting to an ObjectServer using SSL, and the Common Name field of the received certificate does not match the name specified by the Gate.ObjectServerA.Server property or Gate.ObjectServerB.Server (for example, in a failover pair or a virtual server setting), use these properties to specify a comma-separated list of acceptable SSL Common Names. The default setting is to use the Gate.ObjectServerA.Server or Gate.ObjectServerB.Server property.
Gate.ObjectServerA.Debug `boolean` Gate.ObjectServerB.Debug `boolean`	-objectserveradebug `boolean` -objectserverbdebug `boolean`	Use these properties to specify whether the gateway includes debug messages for this ObjectServer in the gateway debug log. The default is TRUE.
Gate.ObjectServerA.DeleteIfNoDedup `boolean` Gate.ObjectServerB.DeleteIfNoDedup `boolean`	-objectserveradelifnodedup `boolean` -objectserverbdelifnodedup `boolean`	Use these properties to specify how the gateway forwards deletes. You have the following options: FALSE: The delete is always applied TRUE: The delete is not applied if the event in the target server indicates that the event has occurred again since the delete was issued. The default is FALSE.
Gate.ObjectServerA.Description `string` Gate.ObjectServerB.Description `string`	-objectserveradescription `string` -objectserverbdescription `string`	Use these properties to specify an application description for the connection to ObjectServer A. This description is used in triggers and allows you to determine which component of the gateway attempted to perform an action. The default is "Gateway Reader/Writer". In a bidirectional ObjectServer gateway configuration, where the gateway connects a primary ObjectServer and a backup ObjectServer, set this property to failover_gate.
Gate.ObjectServerA.DetailsTableName `string` Gate.ObjectServerB.DetailsTableName `string`	-objectserveradetailstblname `string` -objectserverbdetailstblname `string`	Use these properties to specify the name of the details table that the gateway reads. The default is alerts.details.
Gate.ObjectServerA.FailbackEnabled `boolean` Gate.ObjectServerB.FailbackEnabled `boolean`	-objectserverafailbackenabled `boolean` -objectserverbfailbackenabled `boolean`	Use these properties to enable failback for this ObjectServer. The default is FALSE.
Gate.ObjectServerA.FailbackTimeout `integer` Gate.ObjectServerB.FailbackTimeout `integer`	-objectserverafailbacktimeout`integer` -objectserverbfailbacktimeout`integer`	Use these properties to specify the period of time (in seconds) that the gateway must wait before it checks whether the master ObjectServer is back up, so that the gateway can fail back to the master ObjectServer. The default is 30.
Gate.ObjectServerA.IDUCFlushRate `integer` Gate.ObjectServerB.IDUCFlushRate `integer`	-objectserveraiducflushrate `integer` -objectserverbiducflushrate `integer`	Use these properties to control how often the gateway looks for changes in the ObjectServer. The default is 0. If you leave the property set to 0, the ObjectServer can notify the gateway that changes are pending. If you need the gateway to capture more detailed changes to events, set the property to a different value. If you set the property to a value that is not 0, the load on the ObjectServer might be increased.
Gate.ObjectServerA.JournalTableName `string` Gate.ObjectServerB.JournalTableName `string`	-objectserverajournaltblname `string` -objectserverbjournaltblname `string`	Use these properties to specify the name of the journal table that the gateway reads. The default is alerts.journal.
Gate.ObjectServerA.LogOSSql `boolean` Gate.ObjectServerB.LogOSSql `boolean`	-objectserveralogossql `boolean` -objectserverblogossql `boolean`	Use these properties to specify whether the gateway logs all SQL commands sent to this ObjectServer in debug mode. The default is FALSE.
Gate.ObjectServerA.Password `string` Gate.ObjectServerB.Password `string` Set these properties when the ObjectServer is running in secure mode.	-objectserverapassword `string` -objectserverbpassword `string`	Use these properties to specify the password associated with the user specified by the Gate.ObjectServerA.Username property or the Gate.ObjectServerB.Password property, when the ObjectServer is running in secure mode. For more information, see Running the ObjectServer in secure mode. The default is "".
Gate.ObjectServerA.ReconnectTimeout `integer` Gate.ObjectServerB.ReconnectTimeout `integer`	-objectserverareconntimeout `integer` -objectserverbreconntimeout `integer`	Use these properties to specify the time, in seconds, between each reconnection poll attempt if the connection to this ObjectServer is lost. The default is 30.
Gate.ObjectServerA.RefreshCacheOnUpdate `boolean` Gate.ObjectServerB.RefreshCacheOnUpdate `boolean`	-objectserverarefcacheonupd `boolean` -objectserverbrefcacheonupd `boolean`	Use these properties to specify how the hash table cache is refreshed for this ObjectServer. This property is not required for a bidirectional gateway in a failover pair, as the IDUC from the primary ObjectServer is assumed to be accurate. The default is FALSE.
Gate.ObjectServerA.SAF `boolean` Gate.ObjectServerB.SAF `boolean`	-objectserverasaf `boolean` -objectserverbsaf `boolean`	Use these properties to specify whether the gateway stores all changes if the destination ObjectServer is unavailable and to forward them when the ObjectServer becomes available again. The default is FALSE.
Gate.ObjectServerA.SAFFile `string` Gate.ObjectServerB.SAFFile `string`	-objectserverasaffile `string` -objectserverbsaffile `string`	Use these properties to specify the name of the file in which the gateway stores changes while the destination ObjectServer is unavailable. The default is as follows: For the Gate.ObjectServerA.SAFFile property, the default is $OMNIHOME/var/objserv_bi/NCO_GATE_ObjectServerA.store. For the Gate.ObjectServerB.SAFFile, property, the default is $OMNIHOME/var/objserv_bi/ NCO_GATE_ObjectServerB.store. This file is used only if the Gate.ObjectServerA.SAF property or Gate.ObjectServerB.SAF property is set to TRUE.
Gate.ObjectServerA.SAFReplayOnResync `boolean` Gate.ObjectServerB.SAFReplayOnResync `boolean`	-objectserverasafreplayonresync `boolean` -objectserverbsafreplayonresync `boolean`	Use these properties to specify how store-and-forward (SAF) file for ObjectServerA replays before resynchronization. You have the following options: TRUE: SAF replays regardless of whether Gate.Resync.Enable has been set to TRUE. FALSE: SAF replays only when Gate.Resync.Enable has been set to FALSE The default is FALSE.
Gate.ObjectServerA.Server `string` Gate.ObjectServerB.Server `string`	-objectserveraserver `string`-objectserverbserver `string`	Use these properties to specify the name of the ObjectServer that the gateway connects to. The default is NCOMS.
Gate.ObjectServerA.StatusTableName `string` Gate.ObjectServerB.StatusTableName `string`	-objectserverastatustblname `string` -objectserverbstatustblname `string`	Use these properties to specify the name of the status table that the gateway reads. The default is alerts.status.
Gate.ObjectServerA.TblReplicateDefFile `string` Gate.ObjectServerB.TblReplicateDefFile `string`	-objectserveratblrepdeffile `string` -objectserverbtblrepdeffile `string`	Use these properties to specify the path to the table replication definition file. The default is as follows:. For the Gate.ObjectServerA.TblReplicateDefFile property, the default is $OMNIHOME/gates/objserv_bi/objserv_bi.objectservera.tblrep.def For the Gate.ObjectServerB.TblReplicateDefFile property, the default is $OMNIHOME/gates/objserv_bi/objserv_bi.objectservera.tblrep.def
Gate.ObjectServerA.UseBulkInsCmd `boolean` Gate.ObjectServerB.UseBulkInsCmd `boolean`	-usebulkinscmd `boolean` -usebulkinscmd `boolean`	Use these properties to specify bulk inserts for faster resynchronization. You have the following options: TRUE: The gateway changes the format of the insert statement it sends to ObjectServerA, which allows ObjectServerA to process the inserts more efficiently. FALSE: The gateway makes no changes to the insert statement before sending events to ObjectServerA. The default is FALSE.
Gate.ObjectServerA.Username `string` Gate.ObjectServerB.Username `string` Set these properties when the ObjectServer is running in secure mode.	-objectserverausername `string` -objectserverbusername `string`	Use these properties to specify the user name that is used to authenticate the connection to the ObjectServer, when the ObjectServer is running in secure mode. For more information, see Running the ObjectServer in secure mode. The default is root.
Gate.Resync.Enable `boolean`	-resyncenable `boolean`	Use this property to make the gateway resychronize the ObjectServers after the gateway establishes or restablishes a connection to both ObjectServers. For more information, see Configuring resynchronization. The default is TRUE.
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.
Gate.Resync.Master `string`	-resyncmaster `string`	Use this property to specify which ObjectServer the gateway uses as the master during resynchronization. To use the ObjectServer that has been running the longest, leave the property as an empty string. To use a named ObjectServer, regardless of which ObjectServer has been running the longest, set the property to ObjectServerA or ObjectServerB.
Gate.Resync.Preferred `string`	-resyncpreferred `string`	Use this property to specify which ObjectServer the gateway uses as the master during resynchronization if the Gate.Resynch.Master is left empty and both ObjectServers have been running for the same length of time. To use a named ObjectServer, set the property to ObjectServerA or ObjectServerB.
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. For more information about the values to which you can set this property, see Gate.Resync.Type options. The default is NORMAL.

Gate.Resync.Type options

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.