Multiple Identifiers
Transactions can have multiple identifiers. CA IDMS assigns two types of identifiers: a local identifier and a distributed transaction identifier. External transaction managers may assign transaction identifiers of their own, generically referred to as external transaction identifiers.
Local Identifier
A Local (transaction) Identifier (LID) is a four-byte value that identifies the work done by a local transaction branch. It is used to distinguish the work done by one branch from that of another within a central version and is recorded in the journal records that are used to track local database changes (for example, BGIN, BFOR, AFTR). Local transaction identifiers are unique only within a central version.
Distributed Transaction Identifier
A Distributed Transaction Identifier (DTRID) is a 16-byte value that uniquely identifies a distributed transaction across all participating nodes. It is assigned by the CA IDMS system that is acting as the coordinator for the transaction or by a CICS interface. Every distributed transaction processed by a CA IDMS system is assigned a DTRID, regardless of whether the transaction also has externally assigned identifiers. The DTRID is recorded in the distributed transaction journal records that are written during the two-phase commit process (for example, DIND, DCOM, DFGT).
A DTRID value is comprised of an 8-character prefix followed by an 8-byte hexadecimal value. If assigned by a CA IDMS system, the prefix is the system's node name and the suffix is an 8-byte internal format timestamp. If the DTRID is assigned by a CICS interface, the 8-character prefix consists of "CICS" concatenated with the 4-character CICS system name. The 8-byte hexadecimal value is the UOW (Unit of Work) identifier assigned by CICS to the work unit being committed.
External Identifiers
External transaction managers may also assign their own identifiers to a distributed transaction in which CA IDMS is a participant. The following types of external identifiers are recognized by CA IDMS and are recorded in the distributed transaction journal records written by the central version that interfaces directly with the external transaction manager. These journal entries provide a cross reference between internal and external identifiers.
Transaction Branch
A Transaction Branch represents a separately identifiable portion of a transaction within which deadlocks cannot occur. Unless transaction sharing is in effect, every database session (every run unit or SQL database session) is associated with a separate transaction branch. When transaction sharing is in effect, multiple database sessions may share a single transaction branch. In so doing, they avoid deadlocking amongst themselves, since deadlocks are not possible for work performed under a single transaction branch.
An application is associated with multiple transaction branches if it opens concurrent non-sharing database sessions. Multiple branches can also result from the use of system services that access a dictionary, such as loading from a load area or accessing a queue area. If more than one transaction branch exists, they are organized hierarchically, meaning that there is a single top-level branch and one or more subordinate branches. The top-level branch represents either the work done by a single database session or all work done by a task. A subordinate branch always represents the work done by a database session or multiple sessions if transaction sharing is in effect. A subordinate branch may, in turn, have subordinate branches of its own, perhaps as a result of an SQL routine that opens its own database session.
Note: For more information about the relationship between database sessions and transactions and the use of transaction sharing to avoid deadlocks, see either CA IDMS Navigational DML Programming Guide or CA IDMS SQL Programming Guide.
Branch Identifiers
Every transaction branch is assigned a unique identifier that never changes. This Branch Identifier (BID) is an eight-byte hexadecimal value that is sometimes qualified by the node name of the local system to make it a globally unique value. A BID is different from an LID, since an LID is assigned each time a transaction is started, whereas a BID is assigned only when a branch is created. If multiple transactions are serially associated with a transaction branch, because an associated database session commits its work without terminating, then the branch's LID value will change, but its BID will not.
A commit operation is always targeted to a single transaction branch and encompasses all of its subordinate branches. The target branch becomes the top-level branch of the transaction and its subordinates become the subordinate branches of the transaction. If a task-level commit operation is initiated, the target branch is always the top-level branch in the task's hierarchy. If a database session-level commit operation is initiated, the target branch is the one associated with the database session through which the commit request is issued.
It is possible that more than one set of Prepare/Commit flows are sent to a single participant for a transaction, each directed to a different target branch. The BID of the target branch is carried in the associated distributed journal records, in order to distinguish one set from another. The target branch is also included in several messages that may be generated during a two-phase commit operation.
A DCMT DISPLAY DISTRIBUTED TRANSACTION command for a specific transaction lists all of the local branches associated with a distributed transaction. For a description of this command, see the CA IDMS System Tasks and Operator Commands Guide.
|
Copyright © 2014 CA.
All rights reserved.
|
|