You require Fail Safe processing if you need to guarantee data consistency when updating both TIBCO Object Service Broker TDS tables and external DBMS data in a single transaction.
Fail Safe level‑2 processing is not supported.
At Fail Safe level 1, the Gateways reject any update requests within a transaction if the data source (or Oracle SID) in the definition of the SLK table does not match the one specified as the transaction database for the Gateway. If, however, the request is accepted, a table of predefined structure for transaction data to be written (transaction table) is updated. This table’s name is passed to the Gateway in the FSTABLENAME gateway parameter.
The placement of the Gateways’ transaction tables should be made with care. The Gateway can ensure Fail Safe level‑1 data integrity only to the external database containing the transaction table.
At the end of a transaction, the Data Object Broker requests that the Gateway commit outstanding updates. As part of commit processing, the Gateway updates the external transaction table to record the transaction end information. The Gateway then commits its work. If the Gateway does not respond to the Data Object Broker in a reasonable amount of time (or the connection to the Data Object Broker is lost), the transaction is flagged as in-doubt. Locks held on TDS data remain in place until the problem is resolved.
When a connection is re-established between the Data Object Broker and a Gateway with the same configuration as the one that failed, the Data Object Broker asks the Gateway if the in-doubt transaction completed. The Gateway checks the external transaction table to determine this. If the update completed in the external DBMS, the TIBCO Object Service Broker TDS updates are applied. If not, the updates are rolled back. In both cases, the locks are released.