1.1 Glossary

This document uses the following terms:

active phase: The time during the lifetime of an atomic transaction before the commit request when the participants in the transaction (applications and resource managers) perform all their intended work operations inside the transaction.

application: A participant that is responsible for beginning, propagating, and completing an atomic transaction. An application communicates with a transaction manager in order to begin and complete transactions. An application communicates with a transaction manager in order to marshal transactions to and from other applications. An application also communicates in application-specific ways with a resource manager in order to submit requests for work on resources.

atomic transaction: A shared activity that provides mechanisms for achieving the atomicity, consistency, isolation, and durability (ACID) properties when state changes occur inside participating resource managers.

cold recovery: Initial recovery work performed by a transaction manager for a LU 6.2 implementation with respect to a specific LU Name Pair.

cold XLN: The Exchange Log Name messages that are exchanged during cold recovery.

Compare States: In LU 6.2, Compare States messages are sent from one logical unit (LU) to another to convey information about the state of a logical unit of work.

connection: In OleTx, an ordered set of logically related messages. The relationship between the messages is defined by the higher-layer protocol, but they are guaranteed to be delivered exactly one time and in order relative to other messages in the connection.

connection type: A specific set of interactions between participants in an OleTx protocol that accomplishes a specific set of state changes. A connection type consists of a bidirectional sequence of messages that are conveyed by using the MSDTC Connection Manager: OleTx Transports Protocol and the MSDTC Connection Manager: OleTx Multiplexing Protocol transport protocol, as described in [MS-CMPO] and [MS-CMP]. A specified transaction typically involves many different connection types during its lifetime.

conversation: In LU 6.2, conversations connect transaction programs, and are used by the transaction programs to transfer messages.

DTCLU: MSDTC Connection Manager: OleTx Transaction Protocol Logical Unit Mainframe Extension, as specified in [MS-DTCLU].

enlistment: The relationship between a participant and a transaction manager in an atomic transaction. The term typically refers to the relationship between a resource manager and its transaction manager, or between a subordinate transaction manager facet and its superior transaction manager facet.

Exchange Log Name (XLN): In LU 6.2, Exchange Log Name messages are sent from one LU to another to convey information about the state of a log, such as log names and log status.

globally unique identifier (GUID): A term used interchangeably with universally unique identifier (UUID) in Microsoft protocol technical documents (TDs). Interchanging the usage of these terms does not imply or require a specific algorithm or mechanism to generate the value. Specifically, the use of this term does not imply or require that the algorithms described in [RFC4122] or [C706] must be used for generating the GUID. See also universally unique identifier (UUID).

heuristic abort outcome: An outcome of an atomic transaction that indicates that a transaction manager has autonomously made an Abort Outcome decision.

heuristic commit outcome: An outcome of an atomic transaction that indicates that a transaction manager has autonomously made a Commit Outcome decision.

heuristic mixed outcome: An outcome of an atomic transaction that indicates that a participant has autonomously decided the outcome, and the decision is not consistent with the outcome decision made by other participants.

In Doubt outcome: One of the outcomes of an atomic transaction. The In Doubt outcome indicates that a commit request was issued by the root application but that the transaction manager cannot ascertain the actual commit or abort decision.

local log name: A log name that identifies a log held by a local LU.

local LU: An LU 6.2 implementation ([MS-DTCLU] section 3.2) that uses the MSDTC Connection Manager: OleTx Transaction Protocol Logical Unit Mainframe Extension protocol [MS-DTCLU] to communicate with a transaction manager.

log: A durable store used to maintain transaction state.

log status: In LU 6.2, the status of a log can be either Cold or Warm. A log whose status is Cold contains no transaction state. A log whose status is Warm can contain transaction state.

Log Status Cold: A log status value of Cold.

Log Status Warm: A log status of Warm.

logical unit (LU): An addressable network element in the Systems Network Architecture (SNA) defined by IBM that serves as an access point to the network for programs and users, allowing them to access resources and communicate with other programs and users.

logical unit of work (LUW): In LU 6.2, the transaction programs divide the distributed transaction into logical units of work, delimited by Sync Points, to which all participants attempt to synchronize their state.

LU Name Pair: An identifier that uniquely specifies the pairing of a local LU and a remote LU.

LU Type 6.2 (LU 6.2): A type of logical unit designed to provide support for two or more distributed application programs cooperating to carry out some work. All communication provided by LU 6.2 is program-to-program. For more information see [IBM-LU62Guide].

LUW identifier: An identifier for a logical unit of work.

message tag (MTAG): A message that is sent between participants in the context of connections.

outcome: One of the three possible results (Commit, Abort, In Doubt) reachable at the end of a life cycle for an atomic transaction.

participant: Any of the parties that are involved in an atomic transaction and that have a stake in the operations that are performed under the transaction or in the outcome of the transaction ([WSAT10], [WSAT11]).

Phase One: The initial phase of a two-phase commit sequence. During this phase, the participants in the transaction are requested to prepare to be committed. This phase is also known as the "Prepare" phase. At the end of Phase One, the outcome of the transaction is known.

Phase Two: The second phase of a two-phase commit sequence. This phase occurs after the decision to commit or abort is determined. During this phase, the participants in the transaction are ordered to either commit or rollback.

recovery: The process of reestablishing connectivity and synchronizing views on the outcome of transactions between two participants after a transient failure. Recovery occurs either between a resource manager and a transaction manager, or between a Superior Transaction Manager Facet and a Subordinate Transaction Manager Facet.

recovery sequence number: A sequence number used to demarcate sequences of recovery protocol messages to make it possible to detect obsolete recovery protocol messages.

remote log name: A log name that identifies a log held by a remote LU.

remote LU: An LU 6.2 Implementation ([MS-DTCLU] section 3.2) that communicates with the local LU, but without making use of the protocol specified in [MS-DTCLU].

resource manager (RM): The participant that is responsible for coordinating the state of a resource with the outcome of atomic transactions. For a specified transaction, a resource manager enlists with exactly one transaction manager to vote on that transaction outcome and to obtain the final outcome. A resource manager is either durable or volatile, depending on its resource.

session: In OleTx, a transport-level connection between a Transaction Manager and another Distributed Transaction participant over which multiplexed logical connections and messages flow. A session remains active so long as there are logical connections using it.

subordinate transaction manager: A role taken by a transaction manager that is responsible for voting on the outcome of an atomic transaction. A subordinate transaction manager coordinates the voting and notification of its subordinate participants on behalf of its superior transaction manager. When communicating with those subordinate participants, the subordinate transaction manager acts in the role of superior transaction manager. The root transaction manager is never a subordinate transaction manager. A subordinate transaction manager has exactly one superior transaction manager.

superior transaction manager: A role taken by a transaction manager that is responsible for gathering outcome votes and providing the final transaction outcome. A root transaction manager can act as a superior transaction manager to a number of subordinate transaction managers. A transaction manager can act as both a subordinate transaction manager and a superior transaction manager on the same transaction.

Sync Point Processing: In LU 6.2, a distributed error recovery function that allows transaction programs to coordinate error recovery and maintain consistency between distributed resources.

Sync Point Services (SPS): In LU 6.2, the component of the LU that provides support for sync points.

transaction: In OleTx, an atomic transaction.

transaction identifier: The GUID that uniquely identifies an atomic transaction.

transaction manager: The party that is responsible for managing and distributing the outcome of atomic transactions. A transaction manager is either a root transaction manager or a subordinate transaction manager for a specified transaction.

transaction program: In Systems Network Architecture, it is a program that is the direct user of an LU 6.2, or it is executed within an LU 6.2.

transient failure: Any event that could result in a loss of transport connectivity between participants, such as a software crash, a software restart, or a temporary problem with network connections.

two-phase commit: An agreement protocol that is used to resolve the outcome of an atomic transaction in response to a commit request from the root application. Phase One and Phase Two are the distinct phases of the Two-Phase Commit Protocol.

warm recovery: Subsequent recovery work performed by a transaction manager for a LU 6.2 implementation with respect to a specific LU Name Pair. (See cold recovery).

Warm XLN: The Exchange Log Name messages that are exchanged during warm recovery.

work: The set of state changes that are applied to resources inside an atomic transaction.

MAY, SHOULD, MUST, SHOULD NOT, MUST NOT: These terms (in all caps) are used as defined in [RFC2119]. All statements of optional behavior use either MAY, SHOULD, or SHOULD NOT.