Allocation and Sync Point Trees

The allocation tree provides a conceptual structure of the nodes allocating protected conversations within a coordinated transaction. The sync point tree provides a conceptual structure of the nodes initiating sync points within a coordinated transaction. The allocation tree and the sync point tree can be identical. This means the node that allocates the protected conversations is also the node that starts the sync point. There can be cases where the protected conversation is allocated in a node that is different from the node where the sync point originated (this is up to the designer of the distributed application). Figure 1 shows how an allocation tree could differ from a sync point tree for the same coordinated transaction. In this figure, the tree structure is simplified to show only the nodes involved with allocating protected conversations and initiating sync points. The top half of the figure shows an allocation tree and the bottom half of the figure shows the sync point tree for the same coordinated transaction.

In the allocation tree, VM1 is allocating a protected conversation that causes the CRR recovery server at VM1 to provide the LUWID for the coordinated transaction. VM1 allocates a protected conversation to VM2 and VM3. VM3 then allocates a protected conversation to VM4 and VM5. But, now assume a transaction program at VM4 (not VM1) issues a commit verb to start a sync point. This results in a sync point tree that looks different from the allocation tree for the same coordinated transaction.

In the sync point tree, the node (VM4) that starts the sync point is at the top of the sync point tree. VM4 starts a sync point that flows to VM3. VM3 starts a sync point to VM5 and VM1. VM1 then starts a sync point to VM2.

Assuming in this sync point tree there is a communications error between VM3 and VM1 (CRR recovery server on VM3 tries to resynchronize with the CRR recovery server on VM1). VM1 and VM2 still have the LUWID associated with the coordinated transaction when the error between VM3 and VM1 occurred. Before the next sync point starts, the SPM breaks the communication links between VM4 and VM3, and between VM3 and VM5 so VM4, VM3, and VM5 lose the LUWID associated with this coordinated transaction that is in resynchronization. This ensures the LUWID at VM1 and VM2 is not used for a subsequent sync point at VM3, VM4, and VM5. This process of breaking the other parts of the sync point tree is called break tree processing. Break tree processing ensures a unique LUWID is used by each sync point tree after a communication error. For more information about break tree processing, see z/VM: CMS Application Development Guide.