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


Chapter 3 Understanding Fail Safe Processing : Sample Distributed Processing Scenarios

Sample Distributed Processing Scenarios
The following scenarios illustrate Fail Safe processing in environments where there are multiple TIBCO Object Service Broker systems with or without external database servers.
Two Data Object Brokers
Consider a transaction in which a TDS table is updated in Data Object Broker #1 and another TDS table is updated in Data Object Broker #2. The Data Object Brokers are assumed to be connected by a link where the Fail Safe level is 2 as described in the following illustration:
In this case, Data Object Broker #2 is capable of Fail Safe level 2; however, because there is only one service provider and local TDS updates, Fail Safe level 1 provides adequate data integrity.
Commit Cycle for Two Data Object Brokers
The sequence of events for this commit cycle is as follows:
1.
2.
Data Object Broker #1 sends a Fail Safe level‑1 commit to Data Object Broker #2.
3.
4.
5.
When Data Object Broker #1 receives the success message from Data Object Broker #2, it commits its updates (if a failure message is received, it abandons the updates).
6.
Data Object Broker #1 sends a contingency log release directive to Data Object Broker #2 so that the remote contingency log entry can be released.
The same processing occurs if Data Object Broker #2 is an external database server, except for steps #3 and #4. In steps #3 and #4, the transaction database has an update added and the commit is processed by the external database server.
Two Data Object Brokers with an External Database Server
If Data Object Broker #2 has an external database server attached to it involved in the same transaction, it processes the request as for Fail Safe level 1. The following illustrates this process:
Commit Cycle for Two Data Object Brokers with an External Database Server
The sequence of events for this commit cycle is as follows:
1.
2.
Data Object Broker #1 issues a Fail Safe level‑1 Commit to Data Object Broker #2.
3.
4.
Data Object Broker #2 sends a Fail Safe level‑1 commit to the external database.
5.
Data Object Broker #2 commits its TIBCO Object Service Broker transaction, previously saved in the contingency log, and signals Data Object Broker #1 (the commit coordinator) that the commit was successful.
6.
Data Object Broker #1 is not aware that the commit protocol between Data Object Broker #2 and the External Data Server is at Fail Safe level 1.
Three Data Object Brokers
Another possible scenario is a TIBCO Object Service Broker transaction with TDS table updates on three Data Object Brokers as shown in the following:
Commit Cycle for Three Data Object Brokers
Since more than one updated service provider is involved in the transaction and each is capable of supporting Fail Safe level‑2 processing, the sequence of events becomes:
1.
2.
3.
Data Object Brokers #2 and #3 each save their intent lists in their contingency logs and signal Data Object Broker #1 that the prepare to commit was successful.
4.
5.
Multiple Data Object Brokers with an External Database Server
This scenario involves three Data Object Brokers and an external database server:
Commit Cycle for Three Data Object Brokers with External Database Server
At transaction end, the sequence of events is as follows:
1.
Data Object Broker #1 issues a prepare to commit request to Data Object Brokers #2 and #3 and writes its intent list to the contingency log.
2.
3.
4.
5.
When done, Data Object Broker #2 sends a success message back to #1, which completes the commits in Data Object Brokers #1 and #3.
Commit Behavior Across Multiple Data Object Brokers
The following table shows the commit-related actions for the more common combinations of TDS and Fail Safe level settings across two service providers:
Service Provider #1
Service Provider #2
Commit is rejected because a single transaction is not allowed to update more than one service provider with FSlevel = 1.

1
When the service provider is another Data Object Broker, the contingency log provides an equivalent function to the transaction database for Fail Safe level‑1 commits. This database is identified by the TRXDB server parameter. Refer to Transaction Database for information on TRXDB.


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