Compartir a través de

Transaction Confirmation Process

  • Artículo

 

Applies To: Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server Technical Preview, Windows Vista

Message Queuing can use the transactional dead-letter queue of the source computer to indicate that the messages were retrieved from the queue or why the receiving application failed to retrieve them. The presence of a message in the transactional dead-letter queue confirms that it was not retrieved from the destination queue within a fixed time interval, and the message's class (PROPID_M_CLASS or MSMQMessage.MsgClass) indicates the reason why the message was not retrieved.

Note

This confirmation of whether a message was retrieved is completely independent of the application's committing the transaction.

The confirmation process uses the time-to-be-received property, the time-to-reach-queue property (for MSMQ 2.0 and MSMQ 3.0), and the class property of the message, plus the source computer's transactional dead-letter queue. Unconfirmed transactional messages are placed in the transactional dead-letter queue if the source queue manager does not receive a positive confirmation from the remote queue manager that the message was received.

Note

For MSMQ 2.0 and MSMQ 3.0 applications, the journaling level of the message must be set to MQMSG_DEADLETTER to enable the confirmation process. By default, MSMQ 2.0 and MSMQ 3.0 set the journaling level of transactional messages to MQMSG_JOURNAL_NONE.

For MSMQ 1.0 applications, the confirmation process (placing unconfirmed messages into the transactional dead-letter queue of the sending computer) is applied regardless of what the journaling level is set to. In addition, if you are running MSMQ 1.0 applications on an MSMQ 2.0 or MSMQ 3.0 computer, you can force the computer to always set the journaling property to MQMSG_DEADLETTER by setting the XactDeadLetterAlways registry entry to 1.

When the confirmation process is enabled, the source queue manager stores a copy of each message on disk until the outcome of the send operation is known.

Note

The message bytes in these messages consume resources and are counted against the computer quota.

From an application point of view, it is important to understand exactly when the unconfirmed message is placed in the transactional dead-letter queue. Applications must check for the message after the proper time interval. Checking to see whether the unconfirmed message is in the transactional dead-letter queue is the only way that the sending application can be certain of the outcome of the remote receiving operation.

For MSMQ 1.0 applications, the time interval for placing the unconfirmed message in the transactional dead-letter queue is the time-to-be-received setting of the message. The source queue manager places a copy of the message in the transactional dead-letter queue if it does not receive positive confirmation that the message was removed from the destination queue before the time-to-be-received timer of the message expired. Note that if the connection between the source and destination computers is broken before the timer expires, there is a possibility that a copy of the message will be placed in the transactional dead-letter queue even though it was received.

For MSMQ 2.0 and MSMQ 3.0 applications, the time interval is the time-to-be-received setting plus some extended amount, allowing more time for a confirmation to be returned. This additional time can be defined by adding and setting the XactDelayReceiveNack registry entry (there is no default for this setting). If, however, the XactDelayReceiveNack entry does not exist, the additional time is the value of either the time-to-be-received setting or the time-to-reach-queue setting, whichever is smaller.

The following table summarizes how the time-to-be-received timer (TTBR), the time-to-reach-queue timer (TTRQ), and the value set in the XactDelayReceiveNack entry are used to compute the extended time interval. Note that if you do not set the time-to-be-received timer (TTBR), the timer's default value of INFINITE is used. In that case, any additional time is irrelevant.

TTBR TTRQ XactDelay ReceiveNack Extended time interval
Not set.

(INFINITE)		 NA NA INFINITE +
Set NA Set TTBR + XactDelayReceiveNack
Set Not Set Not set TTBR + TTBR
Set Set Not set TTBR + min(TTBR, TTRQ)
Set Set Not set TTBR + min(TTBR, TTRQ)

XactDelayReceiveNack is found under

HKEY_LOCAL_MACHINE  
  SOFTWARE  
    MICROSOFT  
      MSMQ  
        Parameters  
          XactDelayReceiveNack = (time in seconds)

Consequently, the sending application can determine whether the message was confirmed by waiting for the proper interval and then checking whether a copy of the message is in the transactional dead-letter queue.

If the message is not there, the message has been successfully delivered to the destination queue and the receiving application has successfully retrieved it. Message Queuing guarantees this because the source queue manager has received the explicit positive confirmation from the destination queue manager.

If the message is in the transactional dead-letter queue, the sending application can look at the class property of the messages to determine the status of the message. The class property of the message is updated by Message Queuing when it is placed in the transactional dead-letter queue.

More Information

For information on See
Requirements for sending or receiving messages within a transaction Sending and Retrieving Messages within a Transaction
An application used to retrieve messages from remote queues when transaction are needed Transactional Read-response Applications
A summary of the different transaction types provided by Message Queuing Transaction Types
Example code of sending message in different transactions Sending Messages in Transaction Examples