This section gives examples of how to commit and back out recoverable
resources affected by three or more DTP transactions connected on conversations
at sync level 2.
Figure 41 shows the sequence of events for a successful syncpoint
involving six conversing transactions:
- Transaction A
-
- is in conversation with transactions B and D. Before the syncpoint, its
conversations with B and D are in send state.
- is the syncpoint initiator with respect to transactions B and D.
- Transaction B
-
- is in conversation with transactions A, C, and E. Before the syncpoint,
its conversation with A is in receive state, and its conversations with C
and E are in send state.
- is a syncpoint agent of transaction A, and the syncpoint initiator with
respect to transactions C and E.
- Transaction C
-
- is in conversation with transaction B. Before the syncpoint, its conversation
with B is in receive state.
- is a syncpoint agent of transaction B.
- Transaction D
-
- is in conversation with transactions A and F. Before the syncpoint, its
conversation with A is in receive state, and its conversation F is in send
state.
- is a syncpoint agent of transaction A, and the syncpoint initiator with
respect to transaction F.
- Transaction E
-
- is in conversation with transaction B. Before the syncpoint, its conversation
with B is in receive state.
- is a syncpoint agent with respect to transaction B.
- Transaction F
-
- is in conversation with transaction D. Before the syncpoint, its conversation
with D is in receive state.
- is the only syncpoint agent of transaction D.
It illustrates the states and actions that occur when transactions issue
SYNCPOINT requests. To write successful distributed applications you do not
need to understand all the data flows that take place during a distributed
syncpoint. In this example, the programmer is concerned only with issuing
SYNCPOINT in response to finding a conversation in syncreceive state (state 9).
- Transaction A, which is in send state (state
2) on its conversations with transactions B and D, decides to end the distributed
unit of work, and therefore issues a SYNCPOINT command.
- Transaction B sees that its half of its conversation with transaction
A is in syncreceive state (state 9), so it
issues a SYNCPOINT command. Transaction B is responding to a request from
transaction A, but it also becomes the syncpoint initiator for transactions
C and E, and must ensure that its conversations with these transactions are
in a valid state for issuing a SYNCPOINT command. In this example, they are
both in send state (state 2).
- Transaction C sees that its half of its conversation with transaction
B is in syncreceive state (state 9), so it
issues a SYNCPOINT command.
- Transaction E sees that its half of its conversation with transaction
B is in syncreceive state (state 9), so it
issues a SYNCPOINT command.
- Transaction D sees that its half of its conversation with transaction
A is in syncreceive state (state 9), so it
issues a SYNCPOINT command. Transaction D is responding to a request from
transaction A, but it also becomes the syncpoint initiator for transaction
F, and must ensure that its conversation with this transaction is in a valid
state for issuing a SYNCPOINT command. In this example, it is in send state (state 2).
- Transaction F sees that its half of its conversation with transaction
D is in syncreceive state (state 9), so it
issues a SYNCPOINT command.
- All the transactions have now indicated, by issuing SYNCPOINT commands,
that they are ready to commit their changes. This process begins with transaction
F, which has no agents and has responded to "request commit" by issuing
a SYNCPOINT command.
- The distributed syncpoint is complete and control returns to transaction
A following the SYNCPOINT command.
The previous discussion of the SYNCPOINT command assumed that all the agent
transactions were ready to take a syncpoint by issuing SYNCPOINT when their
conversation entered syncreceive state (state
9).
If, however, an agent has detected an error, it can reject the syncpoint
request with one of the following commands:
- SYNCPOINT ROLLBACK (preferred response)
- ISSUE ERROR
- ISSUE ABEND
The SYNCPOINT ROLLBACK command enables a transaction to initiate a backout
operation across the entire distributed unit of work. When it is issued
in response to a syncpoint request, it has the following effects:
- Any changes made to recoverable resources by the transaction that issues
the rollback request are backed out.
- The syncpoint initiator is also backed out (EIBRLDBK set).
This causes the syncpoint initiator to initiate a backout operation
across the distributed unit of work.
Figure 42 shows the sequence of events for a syncpoint involving
six conversing transactions, when one of the agents determines that the distributed
transaction should be backed out. The topology, and initial states are the
same as in Figure 41:
- Transaction A
-
- is in conversation with transactions B and D. Before the syncpoint, its
conversations with B and D are in send state.
- is the syncpoint initiator with respect to transactions B and D.
- Transaction B
-
- is in conversation with transactions A, C, and E. Before the syncpoint,
its conversation with A is in receive state, and its conversations with C
and E are in send state.
- is a syncpoint agent of transaction A, and the syncpoint initiator with
respect to transactions C and E.
- Transaction C
-
- is in conversation with transaction B. Before the syncpoint, its conversation
with B is in receive state.
- is a syncpoint agent of transaction B.
- Transaction D
-
- is in conversation with transactions A and F. Before the syncpoint, its
conversation with A is in receive state, and its conversation F is in send
state.
- is a syncpoint agent of transaction A, and the syncpoint initiator with
respect to transaction F.
- Transaction E
-
- is in conversation with transaction B. Before the syncpoint, its conversation
with B is in receive state.
- is a syncpoint agent with respect to transaction B.
- Transaction F
-
- is in conversation with transaction D. Before the syncpoint, its conversation
with D is in receive state.
- is the only syncpoint agent of transaction D.
As in Figure 41, transaction A (while in send state, state 2) issues the SYNCPOINT command, and CICS® initiates a
chain of events. Here, however, transaction E has detected an error that
makes it unable to commit, and it issues SYNCPOINT ROLLBACK when it detects
that the conversation on its principal facility is in syncreceive state (state 9, EIBSYNC
is also set). This causes any changes that transaction E has made to be backed
out, and initiates a distributed rollback.
Transactions B, C and A are rolled back (EIBRLDBK set). Transaction D senses that the conversation on its principal
facility is in rollback state (state 13,
EIBSYNRB is also set), and issues a
SYNCPOINT ROLLBACK command. Transaction F too senses that the conversation
on its principal facility is in rollback state, and issues a SYNCPOINT ROLLBACK command. The distributed rollback
is now complete.
During the period between the sending of the syncpoint request to the partner
system and the receipt of the reply, the local system does not know whether
the partner system has committed the change. This is known as the indoubt period. If the intersystem session fails during this period,
the local CICS system cannot tell whether the partner system has committed
or backed out its resource changes.
This situation could occur for situations other than DTP and is discussed
in the "Recovery and restart" section of the CICS Intercommunication Guide.
[[ Contents Previous Page | Next Page Index ]]