3.1.1.5 Transactional Message Sequence

To provide EOIO guarantees for transactional messages, the protocol organizes transactional UserMessage Packets ([MS-MQMQ] section 2.2.20) into transactional sequences. A transactional message sequence is independent of the session message sequence of section 3.1.1.4. A transactional message is identified by a sequence number and a transactional sequence identifier pair. The transactional sequence identifier identifies the transaction, and the sequence number identifies the order of the message in that transaction. The first message within a transactional sequence is assigned a sequence number of 1. Only one transactional sequence is active at a given time.

The protocol maintains the following transactional sequence state for each session, as specified in section 3.1.1.3.1:

  • OutgoingTxSequenceID: A TxSequenceID ([MS-MQMQ] section 2.2.18.1.2) that identifies the current outgoing sequence of transactional messages.

  • OutgoingTxSequenceNumber: A 32-bit unsigned integer. This ADM element is the sequence number of the next outgoing transactional UserMessage Packet to be sent on this session.

  • IncomingTxSequenceID: A value that identifies the last incoming transactional message sequence.

  • IncomingTxSequenceNumber: A 32-bit unsigned integer that identifies the sequence number of the last transactional UserMessage Packet received on this session.

  • TxMessageRejectCount: The number of times that the last Message ([MS-MQDMPR] section 3.1.1.12) sent by the remote queue manager was rejected before finally being accepted and placed in the local Queue ([MS-MQDMPR] section 3.1.1.2).

A transactional UserMessage Packet contains a TransactionHeader ([MS-MQMQ] section 2.2.20.5) that specifies the message sequence ID, sequence number, and the sequence number of the previous message in the sequence. This information allows the receiver to determine whether a message is in order and to identify duplicates.

Because messages can expire, gaps are allowed in the transactional sequence numbers. The TransactionHeader includes the previous sequence number so that the receiver can determine whether the received message follows the prior transactional message that was received.

Whenever a transactional message is sent for the first time, the protocol MUST create a new SEQUENCE_INFO ([MS-MQMQ] section 2.2.5) structure instance and set its values as follows:

SeqID to OutgoingTxSequenceID

SeqNo to OutgoingTxSequenceNumber

PrevNo to OutgoingTxSequenceNumber - 1

The new instance MUST be inserted into TxOutgoingSequence.UnackedSequence. When all the messages within a transactional sequence have been acknowledged, the protocol MUST increment the OutgoingTxSequenceID.Ordinal by 1 and MUST reset OutgoingTxSequenceNumber to 1. This process creates a new transactional sequence. Subsequent transactional messages MUST be sent using the new OutgoingTxSequenceID. Messages MUST NOT be sent on prior transactional sequences.

The receiver utilizes transactional sequence numbers when acknowledging receipt of transactional messages. Transactional sequence ID and sequence number values are specified in the OrderAck Packet to acknowledge receipt of transactional messages.

The transactional message sequence mechanism exists alongside the session message sequence specified in section 3.1.1.4. Because transactional messages are recoverable, they are treated as recoverable messages in the session message sequence.

Transactional sequences are end-to-end. Processing of transactional sequences MUST be done only by the original sender queue manager and the final destination queue manager as defined by the queue manager identifier in the UserMessage Packet. An intermediate queue manager that receives a transactional message MUST pass the TransactionHeader to the next destination but perform no processing related to the transactional sequence.