OASIS AMQP Version 1.0
Part 4 : Transactions

Committee Specification Draft 02

29 May 2012

Specification URIs

This version:

http://docs.oasis-open.org/amqp/core/v1.0/csd02/amqp-core-transactions-v1.0-csd02.xml (Authoritative)

http://docs.oasis-open.org/amqp/core/v1.0/csd02/amqp-core-transactions-v1.0-csd02.html

http://docs.oasis-open.org/amqp/core/v1.0/csd02/amqp-core-complete-v1.0-csd02.pdf

Previous version:

http://docs.oasis-open.org/amqp/core/v1.0/csd01/amqp-core-transactions-v1.0-csd01.xml (Authoritative)

http://docs.oasis-open.org/amqp/core/v1.0/csd01/amqp-core-transactions-v1.0-csd01.html

http://docs.oasis-open.org/amqp/core/v1.0/csd01/amqp-core-complete-v1.0-csd01.pdf

Latest version:

http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-transactions-v1.0.xml (Authoritative)

http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-transactions-v1.0.html

http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-complete-v1.0.pdf

Technical Committee:

OASIS AMQP Technical Committee

Chairs:

Ram Jeyaraman (Ram.Jeyaraman@microsoft.com), Microsoft

Angus Telfer (angus.telfer@inetco.com), INETCO Systems

Editors:

Robert Godfrey (robert.godfrey@jpmorgan.com), JPMorgan Chase & Co.

David Ingham (David.Ingham@microsoft.com), Microsoft

Rafael Schloming (rafaels@redhat.com), Red Hat

Additional artifacts:

This specification consists of the following documents:

·        Part 0: Overview - Overview of the AMQP specification

·        Part 1: Types - AMQP type system and encoding

·        Part 2: Transport - AMQP transport layer

·        Part 3: Messaging - AMQP Messaging Layer

·        Part 4: Transactions (this document) - AMQP Transactions Layer

·        Part 5: Security - AMQP Security Layers

·        XML Document Type Definition (DTD)

Related work:

This specification replaces or supersedes:

·        http://www.amqp.org/specification/1.0/amqp-org-download

Abstract:

The Advanced Message Queuing Protocol (AMQP) is an open internet protocol for business messaging. It defines a binary wire-level protocol that allows for the reliable exchange of business messages between two parties. AMQP has a layered architecture and the specification is organized as a set of parts that reflects that architecture. Part 1 defines the AMQP type system and encoding. Part 2 defines the AMQP transport layer, an efficient, binary, peer-to-peer protocol for transporting messages between two processes over a network. Part 3 defines the AMQP message format, with a concrete encoding. Part 4 defines how interactions can be grouped within atomic transactions. Part 5 defines the AMQP security layers.

Status:

This document was last revised or approved by the OASIS AMQP Technical Committee on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the "Send A Comment" button on the Technical Committee's web page at http://www.oasis-open.org/committees/amqp/.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/amqp/ipr.php).

Citation format:

When referencing this specification the following citation format should be used:

[amqp-core-transactions-v1.0]

OASIS AMQP Version 1.0 Part 4 : Transactions. 29 May 2012. Committee Specification Draft 02. http://docs.oasis-open.org/amqp/core/v1.0/csd02/amqp-core-transactions-v1.0-csd02.html.


Notices

Copyright OASIS Open 2012. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.


Table of Contents



4.1 Transactional Messaging
4.2 Declaring a Transaction
4.3 Discharging a Transaction
4.4 Transactional Work
      4.4.1 Transactional Posting
      4.4.2 Transactional Retirement
      4.4.3 Transactional Acquisition
      4.4.4 Interaction of Settlement with Transactions
4.5 Coordination
      4.5.1 Coordinator
      4.5.2 Declare
      4.5.3 Discharge
      4.5.4 Transaction Id
      4.5.5 Declared
      4.5.6 Transactional State
      4.5.7 Txn Capability
      4.5.8 Transaction Error

4.1 Transactional Messaging

Transactional messaging allows for the coordinated outcome of otherwise independent transfers. This extends to an arbitrary number of transfers spread across any number of distinct links in either direction.

For every transactional interaction, one container acts as the transactional resource, and the other container acts as the transaction controller. The transactional resource performs transactional work as requested by the transaction controller.

The transactional controller and transactional resource communicate over a control link which is established by the transactional controller. The declare and discharge messages are sent by the transactional controller over the control link to allocate and complete transactions respectively (they do not represent the demarcation of transactional work). No transactional work is allowed on the control link. Each transactional operation requested is explicitly identified with the desired transaction-id and therefore can occur on any link within the controlling session, or, if permitted by the capabilities of the controller, any link on the controlling connection. If the control link is closed while there exist non-discharged transactions it created, then all such transactions are immediately rolled back, and attempts to perform further transactional work on them will lead to failure.

4.2 Declaring a Transaction

The container acting as the transactional resource defines a special target that functions as a transaction coordinator. The transaction controller establishes a control link to this target. Note that links to the coordinator cannot be resumed.

To begin transactional work, the transaction controller needs to obtain a transaction identifier from the resource. It does this by sending a message to the coordinator whose body consists of the declare type in a single amqp-value section. Other standard message sections such as the header section SHOULD be ignored. This message MUST NOT be sent settled as the sender is REQUIRED to receive and interpret the outcome of the declare from the receiver. If the coordinator receives a transfer that has been settled by the sender, it SHOULD detach with an amqp:illegal-state error.

If the declaration is successful, the coordinator responds with a disposition outcome of declared which carries the assigned identifier for the transaction.

If the coordinator was unable to perform the declare as specified by the transaction controller, the transaction coordinator MUST convey the error to the controller as a transaction-error. If the source for the link to the coordinator supports the rejected outcome, then the message MUST be rejected with this outcome carrying the transaction-error. If the source does not support the rejected outcome, the transactional resource MUST detach the link to the coordinator, with the detach performative carrying the transaction-error.

Transaction controllers SHOULD establish a control link that allows the rejected outcome.

Figure 4.1: Declaring a Transaction
Transaction Controller Transactional Resource =============================================================================== ATTACH(name=txn-ctl, ---------> ..., target= Coordinator( capabilities= "amqp:local-transactions") ) <--------- ATTACH(name=txn-ctl, ..., target= Coordinator( capabilities= ["amqp:local-transactions", "amqp:multi-txns-per-ssn"] ) ) <--------- FLOW(...,handle=1, link-credit=1) TRANSFER(delivery-id=0, ...) ---------> { AmqpValue( Declare() ) } <--------- DISPOSITION(first=0, last=0, state=Declared(txn-id=0) ) -------------------------------------------------------------------------------

4.3 Discharging a Transaction

The controller will conclude the transactional work by sending a discharge message (encoded in a single amqp-value section) to the coordinator. The controller indicates that it wishes to commit or rollback the transactional work by setting the fail flag on the discharge body. As with the declare message, it is an error if the sender sends the transfer pre-settled.

If the coordinator is unable to complete the discharge, the coordinator MUST convey the error to the controller as a transaction-error. If the source for the link to the coordinator supports the rejected outcome, then the message MUST be rejected with this outcome carrying the transaction-error. If the source does not support the rejected outcome, the transactional resource MUST detach the link to the coordinator, with the detach performative carrying the transaction-error. Note that the coordinator MUST always be able to complete a discharge where the fail flag is set to true (since coordinator failure leads to rollback, which is what the controller is asking for).

Figure 4.2: Discharging a Transaction
Transaction Controller Transactional Resource =============================================================================== TRANSFER(delivery-id=0, ...) ---------> { AmqpValue( Declare() ) } <--------- DISPOSITION(first=0, last=0, state=Declared(txn-id=0) ) : Transactional Work : TRANSFER(delivery-id=57, ...) ---------> { AmqpValue( Discharge(txn-id=0, fail=false) ) } <--------- DISPOSITION(first=57, last=57, state=Accepted() ) -------------------------------------------------------------------------------

4.4 Transactional Work

Transactional work is described in terms of the message states defined in section 3.3. Transactional work is formally defined to be composed of the following operations:

The transactional resource performs these operations when triggered by the transaction controller:

In each case, it is the responsibility of the transaction controller to identify the transaction with which the requested work is to be associated. This is done with the transactional delivery state transactional-state that combines a txn-id together with one of the terminal delivery states defined in section 3.4. The transactional-state is carried by both the transfer and the disposition frames allowing both the posting and retiring of messages to be associated with a transaction.

The transfer, disposition, and flow frames can travel in either direction, i.e., from the controller to the resource and from the resource to the controller. When these frames travel from the controller to the resource, any embedded txn-ids are requesting that the resource assigns transactional work to the indicated transaction. When traveling in the other direction, from resource to controller, the transfer and disposition frames indicate work performed, and the txn-ids included MUST correctly indicate with which (if any) transaction this work is associated. In the case of the flow frame traveling from resource to controller, the txn-id does not indicate work that has been performed, but indicates with which transaction future transfers from that link will be performed.

4.4.1 Transactional Posting

If the transaction controller wishes to associate an outgoing transfer with a transaction, it MUST set the state of the transfer with a transactional-state carrying the appropriate transaction identifier. Note that if delivery is split across several transfer frames then all frames MUST be explicitly associated with the same transaction. It is an error for the controller to attempt to discharge a transaction against which a partial delivery has been posted. If this happens, the control link MUST be terminated with the transaction-rollback error.

The effect of transactional posting is that the message does not become available at the destination node within the transactional resource until after the transaction has been successfully discharged.

Figure 4.3: Transactional Publish
Transaction Controller Transactional Resource =============================================================================== TRANSFER(handle=0, ---------> delivery-id=0, ...) { AmqpValue( Declare() ) } <--------- DISPOSITION(first=0, last=0, state=Declared(txn-id=0) ) TRANSFER(handle=1, ---------> delivery-id=1, state= TransactionalState( txn-id=0) ) { ... payload ... } <--------- DISPOSITION(first=1, last=1, state=TransactionalState( txn-id=0, outcome=Accepted()) ) -------------------------------------------------------------------------------

On receiving a non-settled delivery associated with a live transaction, the transactional resource MUST inform the controller of the presumptive terminal outcome before it can successfully discharge the transaction. That is, the resource MUST send a disposition performative which covers the posted transfer with the state of the delivery being a transactional-state with the correct transaction identified, and a terminal outcome. This informs the controller of the outcome that will be in effect at the point that the transaction is successfully discharged.

4.4.2 Transactional Retirement

The transaction controller might wish to associate the outcome of a delivery with a transaction. The delivery itself need not be associated with the same transaction as the outcome, or indeed with any transaction at all. However, the delivery MUST NOT be associated with a different non-discharged transaction than the outcome. If this happens then the control link MUST be terminated with a transaction-rollback error.

To associate an outcome with a transaction the controller sends a disposition performative which sets the state of the delivery to a transactional-state with the desired transaction identifier and the outcome to be applied upon a successful discharge.

Figure 4.4: Transactional Receive
Transaction Controller Transactional Resource =============================================================================== TRANSFER(handle=0, ---------> delivery-id=0, ...) { AmqpValue( Declare() ) } <--------- DISPOSITION(first=0, last=0, state=Declared(txn-id=0) ) FLOW(handle=2, ---------> link-credit=10) <--------- TRANSFER(handle=2, delivery-id=11, state=null, { ... payload ... } : : <--------- TRANSFER(handle=2, delivery-id=20, state=null, { ... payload ... } DISPOSITION(first=11, ---------> last=20, state=TransactionalState( txn-id=0, outcome=Accepted()) ) -------------------------------------------------------------------------------

On a successful discharge, the resource will apply the given outcome and can immediately settle the transfers. In the event of a controller-initiated rollback (a discharge where the fail flag is set to true) or a resource-initiated rollback (the discharge message being rejected, or the link to the coordinator being detached with an error), the outcome will not be applied, and the deliveries will still be "live" and will remain acquired by the controller, i.e., the resource can expect the controller to request a disposition for the delivery (either transactionally on a new transaction, or non-transactionally).

4.4.3 Transactional Acquisition

In the case of the flow frame, the transactional work is not necessarily directly initiated or entirely determined when the flow frame arrives at the resource, but can in fact occur at some later point and in ways not necessarily anticipated by the controller. To accommodate this, the resource associates an additional piece of state with outgoing link endpoints, a txn-id that identifies the transaction with which acquired messages will be associated. This state is determined by the controller by specifying a txn-id entry in the properties map of the flow frame. When a transaction is discharged, the txn-id of any link endpoints will be cleared.

If the link endpoint does not support transactional acquisition, the link MUST be terminated with a not-implemented error.

While the txn-id is cleared when the transaction is discharged, this does not affect the level of outstanding credit. To prevent the sending link endpoint from acquiring outside of any transaction, the controller SHOULD ensure there is no outstanding credit at the sender before it discharges the transaction. The controller can do this by either setting the drain mode of the sending link endpoint to true before discharging the transaction, or by reducing the link-credit to zero, and waiting to hear back that the sender has seen this state change.

If a transaction is discharged at a point where a message has been transactionally acquired, but has not been fully sent (i.e., the delivery of the message will require more than one transfer frame and at least one, but not all, such frames have been sent), then the resource MUST interpret this to mean that the fate of the acquisition is fully decided by the discharge. If the discharge indicates the failure of the transaction the resource MUST abort or complete sending the remainder of the message before completing the discharge.

Figure 4.5: Transactional Acquisition
Transaction Controller Transactional Resource =============================================================================== TRANSFER(handle=0, ---------> delivery-id=0, ...) { AmqpValue( Declare() ) } <--------- DISPOSITION(first=0, last=0, state=Declared(txn-id=0) ) FLOW(handle=2, ---------> link-credit=10, drain=true, properties={ txn-id=0 }) <--------- TRANSFER(handle=2, delivery-id=11, state= TransactionalState(txn-id=0), { ... payload ... } : : <--------- TRANSFER(handle=2, delivery-id=20, state= TransactionalState(txn-id=0), { ... payload ... } DISPOSITION(first=11, ---------> last=20, state=TransactionalState( txn-id=0, outcome=Accepted()) ) -------------------------------------------------------------------------------

4.4.4 Interaction Of Settlement With Transactions

The transport layer defines a notion of settlement which refers to the point at which the association of a delivery-tag to a delivery attempt is forgotten. Transactions do not in themselves change this notion, however the fact that transactional work can be rolled back does have implications for deliveries which the endpoint has marked as settled (and for which it can therefore no longer exchange state information using the previously allocated transport level identifiers).

Transactional Posting

Delivery Sent Settled By Controller

The delivered message will not be made available at the node until the transaction has been successfully discharged. If the transaction is rolled back then the delivery is not made available. If the resource is unable to process the delivery it MUST NOT allow the successful discharge of the associated transaction. This can be communicated by immediately destroying the controlling link on which the transaction was declared, or by rejecting any attempt to discharge the transaction where the fail flag is not set to true.

Delivery Sent Unsettled By Controller; Resource Settles

The resource MUST determine the outcome of the delivery before committing the transaction, and this MUST be communicated to the controller before the acceptance of a successful discharge. The outcome communicated by the resource MUST be associated with the same transaction with which the transfer from controller to resource was associated.

If the transaction is rolled back then the delivery is not made available at the target. If the resource can no longer apply the outcome that it originally indicated would be the result of a successful discharge then it MUST NOT allow the successful discharge of the associated transaction. This can be communicated by immediately destroying the controlling link on which the transaction was declared, or by rejecting any attempt to discharge the transaction where the fail flag is not set to true.

Delivery Sent Unsettled By Controller; Resource Does Not Settle

Behavior prior to discharge is the same as the previous case.

After a successful discharge, the state of unsettled deliveries at the resource MUST reflect the outcome that was applied. If the discharge was unsuccessful then an outcome SHOULD NOT be associated with the unsettled deliveries. The controller SHOULD settle any outstanding unsettled deliveries in a timely fashion after the transaction has discharged.

Transactional Retirement

This section considers the cases where the resource has sent messages to the controller in a non-transactional fashion. For the cases where the resource sends the messages transactionally, see subsection 4.4.3.

Delivery Sent Unsettled By Resource; Controller Settles

Upon a successful discharge the outcome specified by the controller is applied at the source. If the controller requests a rollback or the discharge attempt be unsuccessful, then the outcome is not applied. At this point the controller can no longer influence the state of the delivery as it is settled, and the resource MUST apply the default outcome.

Delivery Sent Unsettled By Resource; Controller Does Not Settle

The resource might or might not settle the delivery before the transaction is discharged. If the resource settles the delivery before the discharge then the behavior after discharge is the same as the case above.

Upon a successful discharge the outcome is applied. Otherwise the state reverts to that which occurred before the controller sent its (transactional) disposition. The controller is free to update the state using subsequent transactional or non-transactional updates.

Transactional Acquisition

Delivery Sent Settled By Resource

In the event of a successful discharge the outcome applies at the resource, otherwise the acquisition and outcome are rolled back.

Delivery Sent Unsettled By Resource; Controller Sends Outcome

An outcome sent by the controller before the transaction has discharged MUST be associated with the same transaction. In the even of a successful discharge the outcome is applied at the source, otherwise both the acquisition and outcome are rolled back.

4.5 Coordination

4.5.1 Coordinator

Target for communicating with a transaction coordinator.

<type name="coordinator" class="composite" source="list" provides="target"> <descriptor name="amqp:coordinator:list" code="0x00000000:0x00000030"/> <field name="capabilities" type="symbol" requires="txn-capability" multiple="true"/> </type>

The coordinator type defines a special target used for establishing a link with a transaction coordinator.

capabilitiesthe capabilities supported at the coordinatoroptional symbol[]

When sent by the transaction controller (the sending endpoint), indicates the desired capabilities of the coordinator. When sent by the resource (the receiving endpoint), defined the actual capabilities of the coordinator. Note that it is the responsibility of the transaction controller to verify that the capabilities of the controller meet its requirements. See txn-capability.

4.5.2 Declare

Message body for declaring a transaction id.

<type name="declare" class="composite" source="list"> <descriptor name="amqp:declare:list" code="0x00000000:0x00000031"/> <field name="global-id" type="*" requires="global-tx-id"/> </type>

The declare type defines the message body sent to the coordinator to declare a transaction. The txn-id allocated for this transaction is chosen by the transaction controller and identified in the declared resulting outcome.

global-idglobal transaction idoptional *

Specifies that the txn-id allocated by this declare MUST be associated with the indicated global transaction. If not set, the allocated txn-id will be associated with a local transaction. This field MUST NOT be set if the coordinator does not have the distributed-transactions capability. Note that the details of distributed transactions within AMQP 1.0 will be provided in a separate specification.

4.5.3 Discharge

Message body for discharging a transaction.

<type name="discharge" class="composite" source="list"> <descriptor name="amqp:discharge:list" code="0x00000000:0x00000032"/> <field name="txn-id" type="*" requires="txn-id" mandatory="true"/> <field name="fail" type="boolean"/> </type>

The discharge type defines the message body sent to the coordinator to indicate that the txn-id is no longer in use. If the transaction is not associated with a global-id, then this also indicates the disposition of the local transaction.

txn-ididentifies the transaction to be dischargedmandatory *
failindicates the transaction has failedoptional boolean

If set, this flag indicates that the work associated with this transaction has failed, and the controller wishes the transaction to be rolled back. If the transaction is associated with a global-id this will render the global transaction rollback-only. If the transaction is a local transaction, then this flag controls whether the transaction is committed or aborted when it is discharged. (Note that the specification for distributed transactions within AMQP 1.0 will be provided separately in Part 6 Distributed Transactions).

4.5.4 Transaction Id

<type name="transaction-id" class="restricted" source="binary" provides="txn-id"/>

A transaction-id can be up to 32 octets of binary data.

4.5.5 Declared

<type name="declared" class="composite" source="list" provides="delivery-state, outcome"> <descriptor name="amqp:declared:list" code="0x00000000:0x00000033"/> <field name="txn-id" type="*" requires="txn-id" mandatory="true"/> </type>

Indicates that a transaction identifier has successfully been allocated in response to a declare message sent to a transaction coordinator.

txn-idthe allocated transaction idmandatory *

4.5.6 Transactional State

The state of a transactional message transfer.

<type name="transactional-state" class="composite" source="list" provides="delivery-state"> <descriptor name="amqp:transactional-state:list" code="0x00000000:0x00000034"/> <field name="txn-id" type="*" mandatory="true" requires="txn-id"/> <field name="outcome" type="*" requires="outcome"/> </type>

The transactional-state type defines a delivery-state that is used to associate a delivery with a transaction as well as to indicate which outcome is to be applied if the transaction commits.

txn-ididentifies the transaction with which the state is associatedmandatory *
outcomeprovisional outcomeoptional *

This field indicates the provisional outcome to be applied if the transaction commits.

4.5.7 Txn Capability

Symbols indicating (desired/available) capabilities of a transaction coordinator.

<type name="txn-capability" class="restricted" source="symbol" provides="txn-capability"> <choice name="local-transactions" value="amqp:local-transactions"/> <choice name="distributed-transactions" value="amqp:distributed-transactions"/> <choice name="promotable-transactions" value="amqp:promotable-transactions"/> <choice name="multi-txns-per-ssn" value="amqp:multi-txns-per-ssn"/> <choice name="multi-ssns-per-txn" value="amqp:multi-ssns-per-txn"/> </type>
local-transactionsamqp:local-transactions

Support local transactions.

distributed-transactionsamqp:distributed-transactions

Support AMQP Distributed Transactions.

promotable-transactionsamqp:promotable-transactions

Support AMQP Promotable Transactions.

multi-txns-per-ssnamqp:multi-txns-per-ssn

Support multiple active transactions on a single session.

multi-ssns-per-txnamqp:multi-ssns-per-txn

Support transactions whose txn-id is used across sessions on one connection.

4.5.8 Transaction Error

Symbols used to indicate transaction errors.

<type name="transaction-error" class="restricted" source="symbol" provides="error-condition"> <choice name="unknown-id" value="amqp:transaction:unknown-id"/> <choice name="transaction-rollback" value="amqp:transaction:rollback"/> <choice name="transaction-timeout" value="amqp:transaction:timeout"/> </type>
unknown-idamqp:transaction:unknown-id

The specified txn-id does not exist.

transaction-rollbackamqp:transaction:rollback

The transaction was rolled back for an unspecified reason.

transaction-timeoutamqp:transaction:timeout

The work represented by this transaction took too long.


<< Part 3: Messaging Part 5: Security >>