Sample Distributed Processing Scenarios

Copyright © Cloud Software Group, 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 illustrated in the following diagram:

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.

Data Object Broker #1 stores its pending updates in the contingency log.

2.

Data Object Broker #1 sends a Fail Safe level‑1 commit to Data Object Broker #2.

3.

Data Object Broker #2 stores its pending updates in its contingency log.

4.

Data Object Broker #2 commits its updates.

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 #6.

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. This process is illustrated as follows:

Commit Cycle for Two Data Object Brokers with an External Database Server

The sequence of events for this commit cycle is as follows:

1.

Data Object Broker #1 logs its intent list to the contingency log.

2.

Data Object Broker #1 issues a Fail Safe level‑1 commit to Data Object Broker #2.

3.

Data Object Broker #2 writes its intent list to the contingency log.

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 completes its commit processing.

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, illustrated as follows:

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.

Data Object Broker #1 issues a prepare to commit to Data Object Brokers #2 and #3.

2.

Data Object Broker #1 saves its intent list in its contingency log.

3.

Data Object Brokers #2 and #3 each save their intent lists in their contingency logs and then signal Data Object Broker #1 that the prepare to commit was successful.

4.

Data Object Broker #1 issues a commit to Data Object Brokers #2 and #3 and does its own local commit.

5.

After Data Object Brokers #2 and #3 confirm their commits and release their contingency logs, the user is notified.

Fail Safe level 2 does not require a contingency log release after the commit request.

Multiple Data Object Brokers with an External Database Server

The following scenario involves three Data Object Brokers and an external database server:

Commit Cycle for Three Data Object Brokers with an 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 it writes its intent list to the contingency log.

2.

Data Object Broker #3 responds that the prepare to commit was successful.

3.

Data Object Broker #2 sends back a message indicating it can handle only Fail Safe level‑1 requests.

4.

Data Object Broker #1 sends another message to Data Object Broker #2 telling it to perform a Fail Safe level‑1 commit.

5.

When this is complete, Data Object Broker #2 sends a success message back to Data Object Broker #1, which then 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:

Transaction updated:

Action

TDS

Service Provider #1

Service Provider #2

Y

Y, FSlevel = 0

N

1. Commit service provider #1.

2. Commit TDS.

Y

Y, FSlevel = 1

N

1. Write TDS updates to contingency log.

2. Commit service provider #1 including updates to the transaction database or equivalent. ¹

3. Commit TDS.

N

Y, FSlevel = 1

N

Commit service provider #1.

Y

Y, FSlevel = 1

Y, FSlevel = 1

Commit is rejected because a single transaction is not allowed to update more than one service provider with FSlevel=1.

Y

Y, FSlevel = 1

Y, FSlevel = 0

Commit is rejected because you cannot mix FSlevel=0 with FSlevel>0 in the same transaction.

N

Y, FSlevel = 1

Y, FSlevel = 0

Commit is rejected.

Y

Y, FSlevel = 1

Y, FSlevel = 2

1. Write intent to contingency log.

2. Issue prepare to commit to service provider #2.

3. Wait for response.

4. Issue Fail Safe level 1 commit to service provider #1.

5. Wait for response.

6. Commit local intent and issue commit to service provider #2.

Y

Y, FSlevel = 2

Y, FSlevel = 2

1. Prepare to commit issued for all three.

2. All three are committed.

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 the TRXDB parameter.

Transaction updated:			Action
TDS	Service Provider #1	Service Provider #2	Action
Y	Y, FSlevel = 0	N	1. Commit service provider #1. 2. Commit TDS.
Y	Y, FSlevel = 1	N	1. Write TDS updates to contingency log. 2. Commit service provider #1 including updates to the transaction database or equivalent. ¹ 3. Commit TDS.
N	Y, FSlevel = 1	N	Commit service provider #1.
Y	Y, FSlevel = 1	Y, FSlevel = 1	Commit is rejected because a single transaction is not allowed to update more than one service provider with FSlevel=1.
Y	Y, FSlevel = 1	Y, FSlevel = 0	Commit is rejected because you cannot mix FSlevel=0 with FSlevel>0 in the same transaction.
N	Y, FSlevel = 1	Y, FSlevel = 0	Commit is rejected.
Y	Y, FSlevel = 1	Y, FSlevel = 2	1. Write intent to contingency log. 2. Issue prepare to commit to service provider #2. 3. Wait for response. 4. Issue Fail Safe level 1 commit to service provider #1. 5. Wait for response. 6. Commit local intent and issue commit to service provider #2.
Y	Y, FSlevel = 2	Y, FSlevel = 2	1. Prepare to commit issued for all three. 2. All three are committed.