AMQP Specification Transport

AMQP Specification.
Session
4.12.6 Command: 0x0204 (executes an extended command)
Signature: execute( options: map, spec: str8, name: str8, arguments: map )
Executes a command from an extended specification.
Field Details:
options: map
options map (optional)
spec: str8
name: str8
an extended specification (optional)
Identifies the specification that defines the behavior for the command. This is typically a URI
identifying a document that contains the formal definition for all the commands in the
extended specification.
the command name (optional)
Identifies the name of the command within the given specification.
arguments: map
the command arguments (optional)
Carries the command arguments as defined by the identified specification.
4.13 Transactional Sessions
A Transactional Session is one in which one of the two Applications using the Session behaves as a
Transactional Resource, and the other behaves as a Transaction Controller. A Transactional Session must be
in one of two modes: "local" or "distributed". In both modes, the Transaction Controller defines transactional
units of work, and indicates whether each unit of work is a success or failure. On a Session with a txn-mode
of "local", each successful unit of work is immediately committed as a complete transaction, and failed units
of work are immediately rolled back. On a Session with a txn-mode of "distributed", each unit of work is
given an xid and becomes part of a distributed transaction that is externally coordinated.
Applications capable of behaving as a Transactional Resource may advertise this when establishing a
Session by setting the txn-support field of the attach control to "local" or "distributed". Applications that
wish to behave as a Transaction Controller may indicate this and choose the mode for the Transactional
Session by setting the txn-mode field of the attach control when establishing a Session. Only one end of a
Session can be the Transaction Controller. It is an error for both Session endpoints to set the txn-mode field
when when establishing a Session.
The transactional implications of each Command are determined by the semantics of the Transactional
Resource. Some Commands sent from the Transaction Controller to the Transactional Resource may modify
transactional state, while others may not. Likewise, some Commands sent from the Resource to the
Controller may carry information about the transactional state of the Resource, while others may not. The
state of the Command Transport itself is not transactional. A Commit or Rollback may negate or confirm the
effects of a Command carried by the Transport, but it has no effect on the command-ids, replay-buffers, or
other Transport related state that falls within the scope of the transaction.
AMQP Transport v. 1-0 Page 35 of 83