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


Chapter 3 Understanding Fail Safe Processing : Fail Safe Strategies

Fail Safe Strategies
Determining a Fail Safe Strategy
If you have a multiple-systems environment, you must decide on an appropriate Fail Safe strategy. To do this, you must determine the Fail Safe level that meets your needs.
Fail Safe Levels
Use the following table to determine your required Fail Safe level:
Commits can be handled serially. External service providers commit first followed by local updates to TDS tables.
Transaction involves a local service for TDS tables and an external service provider. Local updates are contingent upon the completion of external updates.
The following sections describe each Fail Safe level in detail.
Using the Resource Manager facility of the Administration menu, you can identify the maximum Fail Safe level supported by a service provider. During commit processing, the commit coordinator specifies, within defined limits, the commit strategy to use:
Type of Commit Given to Peer Server

1
For all three update types, the local resource is TDS on the local node and the remote resource is a peer.

Fail Safe Level 0 (Serial)
Fail Safe level 0 provides for the issuance of commit requests to each service provider in a commit group, one at a time. If there is only one updated resource, Fail Safe level 0 is adequate. When there are two or more service providers, there is potential for data to get out of sync if an error occurs.
Consider, for example, a commit group that has three service providers:
This is how the Fail Safe process proceeds:
1.
2.
Server 2 is issued a commit. When it responds successfully, the commit continues. Otherwise, if DBPROFILE=1, the commit group is terminated, abandoning all further updates; if DBPROFILE=0, the commit continues.
3.
Data synchronization errors between the service providers can occur if failures or communication loss happens after Server 1 responds successfully to the commit. If Server 1 does not respond, it is unknown whether Server 1 committed or not.
Changes to external resources (peer Data Object Brokers and external databases) are committed in the order in which the resources are first referenced, not necessarily in the order in which the resources are updated.
Fail Safe Level 1 (Contingent)
Fail Safe level 1 is restricted to environments where there are local updates and one service provider with remote (external) updates. An external service provider is capable of Fail Safe level‑1 processing if a transaction database is defined and available. Refer to Transaction Database for more information.
Commit processing under Fail Safe level 1 functions as follows:
1.
The (local) Data Object Broker saves the intent list (that is, the TIBCO Object Service Broker component of the transaction) in the contingency log.
2.
The (remote) external service provider generates a transaction control record and adds it to the pending database updates, then commits. The (local) Data Object Broker commits the intent list after receiving confirmation that the external update was successful.
3.
If connection to the external service provider is lost before commit success or failure notification is received by the originating Data Object Broker, the associated transaction on the contingency log becomes an in-doubt transaction.
4.
When communication is re-established, the external service provider can be queried for the presence or absence of the transaction control record that it added to the pending database updates. This verifies whether it was able to commit the unit of work.
5.
If the control data is not found, the external system did not successfully commit and therefore any associated updates must be abandoned. If it is found, the updates are committed.
Fail Safe Level 2 (Two-Phase Commit)
Fail Safe level 2 coordinates the commit of a database unit of work that is distributed across multiple service providers. To operate at Fail Safe level 2, the participating service providers—a combination of Data Object Brokers and external database servers—must be capable of working with the TIBCO Object Service Broker commit coordination protocol.
In phase 1, when the coordinating service provider signals all other participants to prepare to commit, each participating service provider logs the pending unit of work in its own contingency log.
Having received acknowledgments of a successful phase 1, the coordinator starts phase 2, giving the commit signal, and each service provider actually performs the commit.
Contingent Two-Phase Commit
In this instance, a unit of work is spread across multiple Fail Safe level‑2-capable resources, and one Fail Safe level‑1-capable resource.
Commit processing under this condition functions as follows:
1.
2.
The Fail Safe level‑1-capable resource is signalled to commit and all its commits are completed.
3.
Fail Safe level‑2 commits are completed.
You must identify the highest commit level supported by a resource in the resource manager definitions. For more information about the resource manager, refer to TIBCO Object Service Broker for z/OS Installing and Operating.

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