Share via

3.1.1 Abstract Data Model

  • Article

This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with the behavior that is described in this document.

Note that the abstract data model can be implemented in a variety of ways. This protocol does not prescribe or advocate any specific implementation technique.

Participants MUST use the multiplexing protocol connections specified in [MS-CMP] section 3.1.1.1 as a transport protocol for sending messages. The Transport section 2.1 defines the mechanisms by which this protocol initializes and makes use of the multiplexing protocol.

A participant MUST also maintain the following data elements:

  • Transaction table: A table of entries to transaction objects, keyed by transaction identifier.

  • Session Table: A table of Session objects, as maintained by the multiplexing protocol specified in [MS-CMP] section 3.1.1. The MSDTC Connection Manager: OleTx Transaction Protocol reads the Session table data elements provided by [MS-CMPO] but does not extend or modify the table.

Each transaction object MUST contain the following data structures:

  • Transaction Object.Identifier: This field contains a GUID that specifies the transaction identifier.

  • Connection list: A list of multiplexing protocol connection objects, as specified in [MS-CMP] section 3.1.1.1, that are associated with the transaction.

A transaction object is extended by various participants. When this extension includes enlistment details, then each discrete enlistment is represented in this model as an enlistment object. In this description, the enlistment object represents a set of fields that are always associated with each enlistment. As a group, these fields are referred to in the processing rules as the enlistment object. In the processing rules, a set of fields comprising an enlistment object are always added or removed as a group. Depending on the participant, there can be more than one enlistment object as part of the transaction object (Core Transaction Manager Facet, as specified in section 3.2.1, is an example of this).

An Enlistment object MUST contain the following data structures:

  • Transaction Manager Facet: A reference to the specific facet in the transaction manager that created the Enlistment object. A single facet creates zero or more Enlistment objects. Transaction manager facets are as specified in section 3.2.1.4.

  • Transaction: A reference to a transaction object.

  • Enlistment Object.Connection: A reference to a connection object.

  • Resource Manager Identifier: A GUID that uniquely identifies the resource manager. Each transaction manager facet MUST set this field if the transaction manager facet is communicating with a durable resource manager.

  • Recovery Information: An extensibility point that allows transaction manager facets to contribute information to the durable log that is returned to them when recovery occurs. This field MUST be interpreted only by the transaction manager facet that created the Enlistment object.

  • Name: A string providing a name for the enlistment. Each transaction manager facet MUST define the contents of this field for the Enlistment objects that are created by that facet.

  • Enlistment Object.Identifier: A string providing an identifier for the enlistment. Each transaction manager facet MUST provide the contents of this field for Enlistment objects that are created by that facet.

Furthermore, a participant MUST extend the definition of a connection object to include the following data elements:

  • Transaction: A reference to the transaction object that is associated with the connection.

  • State: A state enumeration that represents the current state of the connection.

  • Connection-Specific Data: An opaque reference to an object. This field is used during the execution of a connection to associate connection-specific objects with the connection. Some connections do not use this field.

A state enumeration MUST contain a set of values that represent specific states in a logical state machine. For a connection type, these values represent the different states to which the connection's logical state machine is set during the lifetime of the connection.

When a participant initiates or accepts a connection, the State field of the connection MUST be set initially to the Idle state. When the connection is disconnected, the connection state MUST be set to the Ended state.

For a participant initiating a connection, once the connection's state machine enters the Ended state, the connection that is associated with the state machine MUST be disconnected, if it is not already disconnected, as specified in section 3.1.8.2.