ISO/IEC 10026-2:1998

Information technology - Open Systems Interconnection - Distributed Transaction Processing - Part 2: OSI TP Service

Technologies de l'information — Interconnexion de systèmes ouverts (OSI) — Traitement transactionnel réparti — Partie 2: Service OSI TP

General Information

• Status: Published
• Publication Date: 21-Oct-1998
• ICS: 35.100.70 - Application layer
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 9093 - International Standard confirmed
• Start Date: 26-Sep-2003
• Completion Date: 30-Oct-2025

Relations

• Revises: ISO/IEC 10026-2:1996 - Information technology - Open Systems Interconnection - Distributed Transaction Processing - Part 2: OSI TP Service
• Effective Date: 15-Apr-2008

Overview

ISO/IEC 10026-2:1998 defines the OSI TP (Open Systems Interconnection Transaction Processing) Service for distributed transaction processing in OSI environments. As Part 2 of the ISO/IEC 10026 series, this standard describes the service-level behaviour, service primitives and functional units that enable coordinated transactions, reliable data transfer and commitment across distributed systems. It is technically aligned with ITU‑T Recommendation X.861.

Key topics

• Functional units and dialogue types: The standard decomposes the OSI TP service into functional units (Dialogue, Shared Control, Polarized Control, Handshake, commitment-related units) and explains how combinations produce different dialogue types.
• Service primitives and parameters: A comprehensive set of OSI TP service primitives (e.g., TP-BEGIN-DIALOGUE, TP-END-DIALOGUE, TP-DATA, TP-U-ERROR, TP-P-ABORT) and their parameters are specified for controlling transaction interactions and signalling.
• Data transfer model: TP-DATA and related primitives describe the modelling of reliable data transfer within a transaction dialogue.
• Control and coordination: Services for grant/request control, handshake operations (TP-HANDSHAKE), and polarised/shared control patterns manage access and sequencing between distributed participants.
• Commitment-related services: Primitive definitions and sequences for transaction lifecycle and outcome coordination are provided - including TP-PREPARE, TP-COMMIT, TP-ROLLBACK, TP-ONE-PHASE, TP-READ-ONLY, TP-HEURISTIC-REPORT and completion/rollback notifications - supporting coordinated commit/abort processing across nodes.
• Service state and contingencies: Annexes and service state tables describe dialogue states, node crash handling, keys and contingency behaviours to ensure predictable service semantics.

Applications

ISO/IEC 10026-2 is practical for:

• Middleware and transaction monitor vendors implementing TP-aware services or OSI-compatible transaction layers.
• System architects and protocol designers building distributed transaction systems, remote procedure frameworks, or enterprise transaction middleware that require explicit dialogue, control and commit semantics.
• Database and distributed application engineers needing standardized behaviour for cross-node transaction coordination, error reporting and recovery.
• Telecommunications and legacy OSI environments where adherence to OSI transaction processing models and ITU‑T alignment (X.861) is required.

Related standards

• ISO/IEC 10026 (other parts) - the broader Distributed Transaction Processing series.
• ITU‑T Recommendation X.861 - closely aligned technical specification.

Keywords: ISO/IEC 10026-2, OSI TP Service, Distributed Transaction Processing, TP-BEGIN-DIALOGUE, TP-DATA, TP-PREPARE, TP-COMMIT, transaction primitives, OSI transaction standard.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 10026-2
Third edition
1998-10-15
Information technology — Open Systems
Interconnection — Distributed Transaction
Processing —
Part 2:
OSI TP Service
Technologies de l'information — Interconnexion de systèmes ouverts
(OSI) — Traitement transactionnel réparti —
Partie 2: Service OSI TP
Reference number
B C
............................................................................................................................................... Page
Contents
Foreword.v
Introduction. vi
1 Scope.1
2 Normative references .1
3 Definitions.1
4 Abbreviations.4
5 Conventions.4
5.1 Service conventions.4
5.2 Usage of the term transaction.5
5.3 Usage of italics for notations.5
6 Overview of the OSI TP Service.6
7 Service facilities.6
7.1 Functional unit descriptions .6
7.2 Services contained in functional units.9
7.3 Service for modelling data transfer.10
7.4 Structure of service descriptions.10
7.5 Effects of dialogue termination .11
8 Service primitives and their parameters .12
9 Data transfer.14
9.1 Overview of data transfer.14
9.2 Data transfer service, TP-DATA .14
10 The Dialogue functional unit .16
10.1 Overview of the Dialogue functional unit.16
10.2 Dialogue Establishment service, TP-BEGIN-DIALOGUE.16
10.3 Dialogue Termination service, TP-END-DIALOGUE.21
10.4 User Error Reporting service, TP-U-ERROR .23
10.5 User Abort service, TP-U-ABORT .25
10.6 Provider Abort service, TP-P-ABORT.28
11 The Shared Control functional unit .30
11.1 Overview of the Shared Control functional unit.30
12 The Polarized Control functional unit.30
12.1 Overview of the Polarized Control functional unit .30
12.2 Grant Control service, TP-GRANT-CONTROL .30
12.3 Request Control service, TP-REQUEST-CONTROL .31
©  ISO/IEC 1998
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced
or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm, without permission in writing from the publisher.
ISO/IEC Copyright Office • Case postale 56 • CH-1211 Genève 20 • Switzerland
Printed in Switzerland
ii
©
ISO/IEC ISO/IEC 10026-2:1998(E)
13 The Handshake functional unit.33
13.1 Overview of the Handshake functional unit .33
13.2 Handshake service, TP-HANDSHAKE.33
13.3 Handshake and Grant Control service, TP-HANDSHAKE-AND-GRANT-CONTROL.35
14 The commitment-related functional units .36
14.1 Introduction .36
14.2 Summary .37
14.3 Overview of the Chained Transactions functional unit.43
14.4 Overview of the Unchained Transactions functional unit.43
14.5 Begin Transaction service, TP-BEGIN-TRANSACTION .43
14.6 Deferred End Dialogue service, TP-DEFERRED-END-DIALOGUE .45
14.7 Deferred Grant Control service, TP-DEFERRED-GRANT-CONTROL .47
14.8 TP-PREPARE request.48
14.9 TP-PREPARE indication.49
14.10 TP-READY indication.50
14.11 TP-COMMIT request .51
14.12 TP-COMMIT indication .53
14.13 TP-DONE request.54
14.14 TP-COMMIT-COMPLETE indication .56
14.15 TP-ROLLBACK request.56
14.16 TP-ROLLBACK indication.57
14.17 TP-ROLLBACK-COMPLETE indication.58
14.18 Heuristic Reporting service, TP-HEURISTIC-REPORT indication .59
14.19 TP-READ-ONLY request .60
14.20 TP-READ-ONLY indication.62
14.21 TP-EARLY-EXIT request.63
14.22 TP-EARLY-EXIT indication.64
14.23 TP-ONE-PHASE request.65
14.24 TP-ONE-PHASE indication.67
14.25 TP-UNKNOWN indication.68
14.26 TP-UNKNOWN-COMPLETE indication.68
14.27 TP-COMPLETION-REPORT indication.69
Annexes
A Service state table.71
A.1 Overview.71
A.2 Dialogue States .71
A.3 Variables.73
A.4 Actions.78
A.5 Node Crash .85
A.6 Keys.85
A.7 Blank Intersections .86
A.8 Node Contingency Table.86
A.9 Service State Table .87
B Summary of changes to the third edition.136
Tables
Table 1 - Functional units and their services .9
Table 2 - Service for modelling data transfer.10
Table 3 - OSI TP service primitives .13
Table 4 - TP-DATA primitives and parameters.14
Table 5 - TP-BEGIN-DIALOGUE primitives and their parameters .16
Table 6 - TP-END-DIALOGUE primitives and their parameter.21
Table 7 - TP-U-ERROR primitives.23
Table 8 - TP-U-ABORT primitives and their parameters .25
Table 9 - TP-P-ABORT indication and its parameters.28
Table 10 - TP-GRANT-CONTROL primitives .30
Table 11 - TP-REQUEST-CONTROL primitives .31
iii
©
Table 12 - TP-HANDSHAKE primitives and their parameter.33
Table 13 - TP-HANDSHAKE-AND-GRANT-CONTROL primitives and their parameter .35
Table 14 - TP-BEGIN-TRANSACTION primitives and their parameter.43
Table 15 - TP-DEFERRED-END-DIALOGUE primitives .45
Table 16 - TP-DEFERRED-GRANT-CONTROL primitives .47
Table 17 - TP-PREPARE request and its parameter.48
Table 18 - TP-PREPARE indication and its parameter .50
Table 19 - TP-READY indication .51
Table 20 - TP-COMMIT request .51
Table 21 - TP-COMMIT indication .53
Table 22 - TP-DONE request and its parameters.54
Table 23 - TP-COMMIT-COMPLETE indication.56
Table 24 - TP-ROLLBACK request.57
Table 25 - TP-ROLLBACK indication and its parameters.57
Table 26 - TP-ROLLBACK-COMPLETE indication .59
Table 27 - TP-HEURISTIC-REPORT indication and parameter.59
Table 28 - TP-READ-ONLY request and its parameter.60
Table 29 - TP-READ-ONLY indication.62
Table 30 - TP-EARLY-EXIT request and its parameters.63
Table 31 - TP-EARLY-EXIT indication and its parameters.64
Table 32 - TP-ONE-PHASE request.65
Table 33 - TP-ONE-PHASE indication .67
Table 34 - TP-UNKNOWN indication.68
Table 35 - TP-UNKNOWN-COMPLETE indication.68
Table 36 - TP-COMPLETION-REPORT indication and its parameters.69
Figures
Figure 1 - Combination of functional units and resulting dialogue types .8
Figure 2 - Unconfirmed TP-BEGIN-DIALOGUE sequence of primitives .19
Figure 3 - Confirmed TP-BEGIN-DIALOGUE sequence of primitives .19
Figure 4 - Unconfirmed TP-END-DIALOGUE sequence of primitives.21
Figure 5 - Confirmed END-DIALOGUE sequence of primitives.22
Figure 6 - TP-U-ERROR sequence of primitives.23
Figure 7 - TP-U-ERROR as the negative confirmation to a handshake service.24
Figure 8 - TP-U-ABORT sequence of primitives.26
Figure 9 - TP-P-ABORT sequence of primitives.29
Figure 10 - TP-GRANT-CONTROL sequence of primitives .30
Figure 11 - TP-REQUEST-CONTROL sequence of primitives .32
Figure 12 - TP-HANDSHAKE sequence of primitives .33
Figure 13 - TP-HANDSHAKE-AND-GRANT-CONTROL sequence of primitives.35
Figure 14 - TP-BEGIN-TRANSACTION sequence of primitives .44
Figure 15 - TP-DEFERRED-END-DIALOGUE sequence of primitives .45
Figure 16 - TP-DEFERRED-GRANT-CONTROL sequence of primitives .47
iv
©
ISO/IEC ISO/IEC 10026-2:1998(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members
of ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC
JTC 1. Draft International Standards adopted by the joint technical committee are circulated to national
bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national
bodies casting a vote.
International Standard ISO/IEC 10026-2 was prepared by Joint Technical Committee ISO/IEC JTC 1,
Information technology, Subcommittee SC 21, Open systems interconnection, data management and open
distributed processing.
This third edition cancels and replaces the second edition (ISO/IEC 10026-2:1996), which has been
technically revised.
This part of ISO/IEC 10026 is technically aligned with ITU-T Recommendation X.861, but is not published as
identical text.
ISO/IEC 10026 consists of the following parts, under the general title Information technology — Open
Systems Interconnection — Distributed Transaction Processing:
— Part 1: OSI TP Model
— Part 2: OSI TP Service
— Part 3: Protocol specification
— Part 4: Protocol Implementation Conformance Statement (PICS) proforma
— Part 5: Application context proforma and guidelines when using OSI TP
— Part 6: Unstructured Data Transfer
Annex A forms an integral part of this part of ISO/IEC 10026. Annex B is for information only.
v
©
Introduction
ISO/IEC 10026 is one of a set of standards produced to facilitate the interconnection of computer systems. It
is related to other International Standards in the set as defined by the Reference Model for Open Systems
Interconnection (ISO/IEC 7498-1). The Reference Model subdivides the area of standardization for
interconnection into a series of layers of specification, each of manageable size.
The aim of Open Systems Interconnection is to allow, with a minimum of technical agreement outside the
interconnection standards, the interconnection of computer systems
a) from different manufacturers;
b) under different management;
c) of different levels of complexity; and
d) of different technologies.
ISO/IEC 10026 defines an OSI TP Model, an OSI TP Service and specifies an OSI TP Protocol available
within the Application Layer of the OSI Reference Model.
The OSI TP Service is an Application Layer service. It is concerned with information which can be related as
distributed transactions, which involve two or more open systems.
This part of ISO/IEC 10026 defines a basic OSI TP Service. It provides sufficient facilities to support
transaction processing, and establishes a framework for coordination across multiple TP resources in
separate open systems.
ISO/IEC 10026 does not specify the interface to local resources or access facilities that are provided within
the local system. However, future enhancement of the standard may deal with these issues.
vi
©
INTERNATIONAL STANDARD  ISO/IEC ISO/IEC 10026-2:1998(E)
Information technology — Open Systems
Interconnection — Distributed Transaction Processing —
Part 2:
OSI TP Service
1 Scope
This part of ISO/IEC 10026 defines in an abstract way the Distributed Transaction Processing Service within
the Application Layer in terms of:
a) the actions and events of the service primitives;
b) the parameter data associated with each service primitive's action and event; and
c) the relationship between, and the valid sequences of these actions and events.
It does not specify individual implementations or products, nor does it constrain the implementation of entities
or interfaces within a computer system.
2 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of this
part of ISO/IEC 10026. At the time of publication, the editions indicated were valid. All standards are subject
to revision, and parties to agreements based on this part of ISO/IEC 10026 are encouraged to investigate the
possibility of applying the most recent editions of the standards indicated below. Members of ISO and IEC
maintain registers of currently valid International Standards.
ISO/IEC 7498-1:1994, Information technology - Open Systems Interconnection - Basic Reference Model: The
Basic Model.
Information technology - Open Systems Interconnection - Basic Reference Model:
ISO/IEC 7498-3:1997,
Naming and addressing.
ISO/IEC 8649:1996, Information technology - Open Systems Interconnection - Service definition for the
Association Control Service Element.
ISO/IEC 10026-1:1998, Information technology - Open Systems Interconnection - Distributed Transaction
Processing - Part 1: OSI TP Model.
ISO/IEC 10026-3:1998, Information technology - Open Systems Interconnection - Distributed Transaction
Processing - Part 3: Protocol specification.
ISO/IEC 10731:1994, Information technology - Open Systems Interconnection - Basic Reference Model -
Conventions for the definition of OSI services.
3 Definitions
For the purposes of this part of ISO/IEC 10026, the definitions given in ISO/IEC 10026-1 and the following
definitions apply.
©
3.1 dialogue establishment indication outstanding: A dialogue state in which a TP-BEGIN-DIALOGUE
indication with the Confirmation parameter set to "always" has been issued but has not yet been responded
to by a TP-BEGIN-DIALOGUE response.
3.2 dialogue establishment request outstanding: A dialogue state in which a TP-BEGIN-DIALOGUE
request with the Confirmation parameter set to "always" has been issued but has not yet been responded to
by a TP-BEGIN-DIALOGUE confirm.
: A dialogue state in which a TP-END-DIALOGUE
3.3 dialogue termination indication outstanding
user error request
indication with the Confirmation parameter set to "true" has been issued while there is no
outstanding
, but has not yet been responded to by a TP-END-DIALOGUE response, or by a TP-U-ERROR
request.
3.4 dialogue termination request outstanding: A dialogue state in which a TP-END-DIALOGUE request
with the Confirmation parameter set to "true" has been issued, but has not yet been responded to by a TP-
END-DIALOGUE confirm, or by a TP-U-ERROR indication.
3.5 exclusive branch: A transaction branch on which one of the following is true:
- the dialogue is with the superior, ready can be sent, and either:
- ready can not be received; or
- there is tree checking at the node;
- the dialogue is with a subordinate, ready can be sent, ready can not be received, and either:
- the Read-only functional unit is not selected and the Early-exit functional unit is not selected; or
- there is tree checking at the node; or
- the dialogue is with a subordinate and the coordination level is "one-phase commitment" and either:
- the Read-only functional unit is not selected and the Early-exit functional unit is not selected; or
- there is tree checking at the node;
and if the Unchained Transactions functional unit is selected, none of the following service primitives have
been issued during the current transaction: TP-READY indication, TP-READ-ONLY indication, TP-ONE-
PHASE indication, or TP-EARLY-EXIT indication.
3.6 handshake indication outstanding: A dialogue state in which one of the following service primitives:
- TP-HANDSHAKE indication;
- TP-HANDSHAKE-AND-GRANT-CONTROL indication;
has been issued while there is no user error request outstanding, but has not yet been responded to by one
of the following service primitives (respectively):
- TP-HANDSHAKE response;
- TP-HANDSHAKE-AND-GRANT-CONTROL response;
the dialogue is coordinated
or by a TP-U-ERROR request, or, if , by a TP-EARLY-EXIT request or a TP-
rollback-initiating service primitive
EARLY-EXIT indication or any .
3.7 handshake request outstanding: A dialogue state in which one of the following service primitives:
- TP-HANDSHAKE request;
- TP-HANDSHAKE-AND-GRANT-CONTROL request;
has been issued, but has not yet been responded to by one of the following service primitives (respectively):
- TP-HANDSHAKE confirm;
- TP-HANDSHAKE-AND-GRANT-CONTROL confirm;
or by a TP-U-ERROR indication, or, if the dialogue is coordinated, by a TP-EARLY-EXIT request or a TP-
EARLY-EXIT indication or any rollback-initiating service primitive.
superior can send ready
3.8 ready can be received (on a branch) if the branch is with a superior and on the
branch, or the branch is with a subordinate and subordinate can send ready on the branch.
©
ISO/IEC ISO/IEC 10026-2:1998(E)
subordinate can send ready
3.9 ready can be sent (on a branch) if the branch is with the superior and on
superior can send ready
the branch or the branch is with a subordinate and on the branch.
3.10 rollback-initiating indication: An indication or confirm that triggers a rollback; it is one of the following
service primitives:
- TP-ROLLBACK indication;
- TP-U-ABORT indication with the Rollback parameter set to "true";
- TP-P-ABORT indication with the Rollback parameter set to "true";
- TP-BEGIN-DIALOGUE confirm with the Rollback parameter set to "true".
3.11 rollback-initiating request: A request that triggers a rollback; it is one of the following service
primitives:
- TP-ROLLBACK request;
- TP-U-ABORT request for a coordinated dialogue not issued during the termination phase of a transaction
and neither a TP-READ-ONLY indication nor a TP-EARLY-EXIT indication has been issued for the
dialogue.
: A service primitive that triggers a rollback; it may be either a
3.12 rollback-initiating service primitive
rollback-initiating request rollback-initiating indication
or a .
3.13 static one-phase exclusive branch: An exclusive branch on which the coordination level is “one-
phase commitment”.
NOTE - this is only defined for a branch to a subordinate.
3.14 subordinate dialogue: A dialogue with a subordinate.
3.15 subordinate can send ready (on a branch) if the branch is with a subordinate and the Commit
functional unit is selected and the Dynamic Commit functional unit is not selected, or the Dynamic Commit
functional unit is selected and the Subordinate-may-send-ready parameter of TP-BEGIN-DIALOGUE request
was set to "true".
3.16 subordinate subtree: A subtree of a subordinate.
3.17 superior can send ready (on a branch) if the branch is with the superior and the Dynamic Commit
functional unit is selected and the Superior-may-send-ready parameter of TP-BEGIN-DIALOGUE indication
was set to "true".
3.18 superior dialogue: The dialogue with the superior.
3.19 termination phase of a transaction; termination phase: The phase of a transaction between
initiation of commitment or rollback and the end of the transaction.
This phase is entered, for a given TPSUI, upon issuance of a transaction completion request or a TP-
EARLY-EXIT request or any rollback-initiating service primitive.
For a TPSUI which does not have a dialogue establishment indication outstanding, this phase is exited upon
issuance of a TP-COMMIT-COMPLETE indication or a TP-UNKNOWN-COMPLETE indication or a TP-
ROLLBACK-COMPLETE indication.
For a TPSUI which does have a dialogue establishment indication outstanding when the termination phase is
entered (this can only happen when a TP-ROLLBACK indication is issued), this phase is exited by a TP-
BEGIN-DIALOGUE response with the Result parameter set to "rejected(user)" or by a TP-P-ABORT
indication for the dialogue; if the dialogue is accepted during the termination phase, the termination phase is
exited by the subsequent TP-ROLLBACK-COMPLETE indication.
3.20 TPSUI owes a TP-DONE request: This obligation is created by the issuing of certain indications and
confirmations during termination of a transaction; the TPSUI must issue a TP-DONE request before the
transaction can be completed.
3.21 transaction completion request: A service request which triggers completion (rather than rollback) of
a transaction; it is one of the following service primitives:
- TP-COMMIT request;
- TP-READ-ONLY request;
- TP-ONE-PHASE request.
©
coordinated dialogue
3.22 transaction subordinate: A TPSUI which is the subordinate for a .
3.23 transaction superior: A TPSUI which is the superior for one or more coordinated dialogues.
3.24 transaction tree constraint: A constraint that cannot be checked at a single node.
3.25 tree checking: There is tree checking at a node if there is a transaction branch from the superior on
which either:
- ready can be sent and ready can be received and the Check-ready-directions parameter of the TP-
BEGIN-DIALOGUE indication or the TP-BEGIN-TRANSACTION indication for the current transaction
was absent or set to "true"; or
- ready can be sent, and ready can not be received.
There may also be tree checking at a node (including at a root node) as the result of a local decision.
NOTE - this would typically occur as the result of configuration information on a real open system.
3.26 two-phase expected branch: A transaction branch on a coordinated dialogue with a subordinate, on
which ready can be received and either:
- none of the One-phase, Read-only, and Early-exit functional units are selected; or
tree checking
- the Unchained Transactions functional unit is selected, there is at the node, and none of
the following service primitives have been issued during the current transaction: TP-ONE-PHASE
indication, TP-READ-ONLY indication, or TP-EARLY-EXIT indication.
3.27 user error indication outstanding: A state of a dialogue with the Polarized Control functional unit
selected. In this state, a TP-U-ERROR indication, issued while the recipient had control of the dialogue and
has neither a handshake request outstanding nor a dialogue termination request outstanding, has not yet
the dialogue is coordinated
been responded to by a TP-GRANT-CONTROL request, or, if , by a TP-EARLY-
rollback-initiating service primitive
EXIT request or a TP-EARLY-EXIT indication or any .
3.28 user error request outstanding: A state of a dialogue with the Polarized Control functional unit
selected. In this state, a TP-U-ERROR request, issued without having control of the dialogue and without
having either a handshake indication outstanding or a dialogue termination indication outstanding, has not yet
been responded to by a TP-GRANT-CONTROL indication, a TP-HANDSHAKE indication, a TP-
HANDSHAKE-AND-GRANT-CONTROL indication, a TP-END-DIALOGUE indication with the Confirmation
parameter set to "true", or, if the dialogue is coordinated, by a TP-EARLY-EXIT request or a TP-EARLY-EXIT
rollback-initiating service primitive
indication or any .
4 Abbreviations
Abbreviations used in this part of ISO/IEC 10026 are defined in ISO/IEC 10026-1 (OSI TP Model), except for
the following which are used in some tables:
cnf confirm service primitive;
ind indication service primitive;
req request service primitive;
rsp response service primitive.
5 Conventions
5.1 Service conventions
This part of ISO/IEC 10026 defines services for Distributed Transaction Processing guided by the descriptive
conventions defined in ISO/IEC 10731.
However, the terms "request" and "indication" are sometimes used in the following ways:
a) a single request may result in multiple indications (an example is that a single TP-COMMIT request may
result in TP-PREPARE indications to each direct subordinate TPSUI);
©
ISO/IEC ISO/IEC 10026-2:1998(E)
b) several requests may result in a single indication (an example is that a single TP-COMMIT-COMPLETE
indication may be issued to a superior TPSUI only after TP-DONE requests have been issued by this
TPSUI and by all subordinate TPSUIs in the transaction tree);
c) the convention that a request primitive results in an indication primitive of the same name, is not always
followed (for example, the issuance of a TP-COMMIT request may cause a TP-PREPARE indication to
be issued).
NOTE - In this part of ISO/IEC 10026, requests and responses are described as being issued by the TPSUI
whereas indications and confirms are described as being issued by the TPSP.
For a given primitive, the presence of each parameter is described by one of the following values:
blank: not applicable;
M: presence is mandatory;
U: presence is a user option;
O: presence is a provider option; and,
C: presence is conditional.
In addition the notation (=) indicates that a parameter value is semantically equal to the value of the
parameter of the preceding primitive in the table.
5.2 Usage of the term transaction
In this part of ISO/IEC 10026, the term "transaction" is used to denote a distributed provider-supported
transaction.
5.3 Usage of italics for notations
In this part of ISO/IEC 10026, the following notations, defined in clause 3 or in 10026-1, appear in italics:
- commitment hinterland;
- coordinated dialogue; dialogue is coordinated;
- dialogue establishment indication outstanding;
- dialogue establishment request outstanding;
- dialogue termination indication outstanding;
- dialogue termination request outstanding;
- exclusive branch;
- handshake indication outstanding;
- handshake request outstanding;
- ready can be received;
- ready can be sent;
- rollback-initiating indication;
- rollback-initiating request;
- rollback-initiating service primitive;
- static one-phase exclusive branch;
- subordinate can send ready;
- subordinate dialogue;
- subordinate subtree;
- superior can send ready;
- superior dialogue;
- termination phase [of a transaction];
- there is tree checking;
- TPSUI owes a TP-DONE request;
- transaction completion request;
- transaction hinterland;
- transaction subordinate;
- transaction superior;
- transaction tree constraint;
- two-phase expected branch;
- user error indication outstanding;
- user error request outstanding.
©
6 Overview of the OSI TP Service
The Distributed Transaction Processing Service and its supporting protocol are concerned with creating an
environment in which two or more users may interact to
a) establish dialogues;
b) invoke services of specific user application service elements, subject to the constraints of the TPSP;
c) delimit provider-supported transactions;
d) coordinate work for application-supported transactions or provider-supported transactions;
e) prepare for commitment, and commit or roll back a provider-supported transaction;
f) heuristically place bound data either in the final or initial state;
g) report errors;
h) terminate dialogues allowing all resources allocated to these dialogues to be freed;
i) terminate dialogues abnormally;
j) synchronize processing by handshaking;
k) support chained or unchained sequences of provider-supported transaction branches for a dialogue.
A node crash may result in the TPSP issuing certain TP service primitives more than once (i.e., TP-COMMIT
indication, TP-ROLLBACK indication, and TP-HEURISTIC-REPORT indication). The TPSP and the TPSUI
are both aware of the node crash through local means.
7 Service facilities
7.1 Functional unit descriptions
The following functional units are defined:
a) Dialogue: the Dialogue functional unit supports the basic services required to establish a dialogue
between two TPSUIs within which U-ASE primitives may be invoked, signal user-initiated errors and
terminate the dialogue. The user or the provider may signal abnormal termination;
b) Shared Control: the Shared Control functional unit supports both TPSUIs having control of the
dialogue at the same time and allows them to issue request primitives subject only to the normal
sequencing constraints of the primitives. For example, data may be transferred by both TPSUIs at the
same time;
c) Polarized Control: the Polarized Control functional unit allows only one TPSUI to have control of the
dialogue at any point in time. Many request primitives may be issued only by the TPSUI which has
control of the dialogue. This restriction is in addition to the normal sequencing constraints for the
primitives. For example, a handshake may only be requested by the TPSUI which has control of the
dialogue;
d) Handshake: the Handshake functional unit allows the TPSUIs to synchronize their processing with
one another;
e) : the Commit functional unit allows reliable commitment and rollback of transactions;
Commit
f) Chained Transactions: the Chained Transactions functional unit supports coordination of both
TPSUIs with a chained sequence of transaction branches. The coordination level of the dialogue will
always be "commitment" or "one-phase commitment". The subordinate TPSUI will always be a
participant in the same transaction as the superior TPSUI;
g) Unchained Transactions: the Unchained Transactions functional unit supports coordination of both
TPSUIs with an unchained sequence of transaction branches. The superior determines when the
coordination level of the dialogue is "commitment" or "one-phase commitment". At a given point in
time, the two TPSUIs may be participants in the same transaction, in different transactions, or one or
both TPSUIs may not be involved in a transaction;
©
ISO/IEC ISO/IEC 10026-2:1998(E)
h) Dynamic Commit: the Dynamic Commit functional unit allows the reliable commitment of a
transaction to be organised in a way which is not limited by the orientation of the supporting dialogue
tree;
i) Unchecked Tree: the Unchecked Tree functional unit allows the suppression of TPSP checks on the
construction of transaction trees when the Dynamic Commit functional unit is selected;
j) the Implicit Prepare functional unit allows the signal that the transaction is to be
Implicit Prepare:
completed to be carried in application semantics such that an explicit TP service indication may not be
required;
k) Read-only: the Read-only functional unit allows a TPSUI which has completed processing of all work
related to a transaction to request that it withdraw from participation in the transaction if it has not
modified its bound data;
l) Early-exit: the Early-exit functional unit allows a TPSUI to indicate that it is unable to contribute to the
work of a transaction, its bound data has not been modified, and that the TPSUI has no preference as
to whether the transaction commits or is rolled back;
m) One-phase Commit: the One-phase Commit functional unit allows a TPSUI that has no requirement
for reliable reporting of the outcome of a transaction to request one-phase termination of that
transaction;
n) Completion Diagnostics: the Completion Diagnostics functional unit allows a TPSUI to signal
information related to the completion of a transaction to its superior TPSUI in the transaction tree,
including the severity and reason for a rollback request;
o) Heuristic Containment Required: the Heuristic Containment Required functional unit allows a
TPSUI to require its subordinate to contain heuristic conditions; as a result the TPSUI will not receive
heuristic reports from the subordinate.
The Dialogue functional unit shall always be selected.
For a given dialogue, the Shared Control and Polarized Control functional units are mutually exclusive. One
and only one of these two functional units shall be selected.
For a given dialogue, the One-phase Commit functional unit may be selected alone (static one-phase
commit) or together with both of the Commit and Dynamic Commit functional units (dynamic one-phase
commitment).
For a given dialogue, the Chained Transactions and Unchained Transactions functional units are mutually
exclusive. If either or both of the Commit or One-phase Commit functional units are selected, one and only
one of the Chained Transactions and Unchained Transactions functional units shall be selected. If neither
the Commit nor the One-phase Commit functional unit is selected, neither one of the Chained Transactions
or Unchained Transactions functional units shall be selected.
For a given dialogue, if the Commit functional unit is selected, then one or more of the following functional
units may also be selected in any combination: Implicit Prepare, Read-only, Early-exit, Completion
Diagnostics, Heuristic Containment Required.
For a given dialogue, if the One-phase Commit functional unit is selected and the Commit functional unit is
not selected, then one or more of the following functional units may also be selected in any combination:
Implicit Prepare, Read-only, Early-exit, Completion Diagnostics, Heuristic Containment Required.
For a given dialogue, only if the Commit and Unchained Transactions functional units are selected may the
Dynamic Commit functional unit be selected. If the Dynamic Commit functional unit is selected, then the
Unchecked Tree functional unit may also be selected.
NOTE - There are multi-dialogue constraints on functional units, which apply when transaction branches are created by
TP-BEGIN-DIALOGUE request or TP-BEGIN-TRANSACTION request. For example, the static one-phase commit
capability may be selected for a subordinate transaction branch only if there is no superior transaction branch. Such
constraints are defined in the descriptions of the relevant services.
With the rules given above the following dialogue types are valid:
©
application supported transaction
Dialogue branches
static two-phase commitment with
Commit
unchained transaction branches
dynamic two-phase commitment with
Dynamic Commit
unchained transaction branches
dynamic two-phase commitment or
One-phase Commit dynamic one-phase commitment with
unchained transaction branches
static two-phase commitment with
Chained
...