Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 3 Configuring and Operating : Implementing Fail Safe Processing

Implementing Fail Safe Processing
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.
Options for Fail Safe Processing
There are two Fail Safe processing levels available with the Gateway:
At Fail Safe level-0, no Fail Safe processing is performed.
At Fail Safe level‑1, one external DBMS, denoted by an ODBC data source or Oracle SID, can be assigned as a transaction database so Fail Safe processing can be performed at the end of a transaction, if warranted by the nature of that transaction.
Fail Safe level‑2 processing is not supported.
Requirements for Fail Safe Level‑1 Processing
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.
Fail Safe Processing and In-doubt Transactions
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.
Determining the State of the External Data
The table below shows how the Gateway reads the transaction database to determine the state of the external data.
If the external DBMS data is...
The Data Object Broker rolls forward the in-doubt TIBCO Object Service Broker transaction by committing TIBCO Object Service Broker data and releasing locks.
The Data Object Broker rolls back the in-doubt TIBCO Object Service Broker transaction by discarding the intent list and releasing locks.
You can resolve in-doubt transactions only by starting a Gateway with exactly the same parameter settings as the Gateway in use at the time the transaction was placed in doubt.

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved