Programming Considerations with Transactions
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
To perform a transaction, your application may need to work with Microsoft® Distributed Transaction Coordinator (MS DTC) and all resource managers needed to complete the transaction. These include all the resource managers associated with the transaction, including Message Queuing and MS DTC as the transaction manager. MS DTC is not needed for internal transactions.
From a system perspective, the process of performing a transaction starts with the transaction application asking MS DTC or Message Queuing for a new transaction object. Once a transaction object is available, the application can then make any number of transactional calls to all the resource managers needed by the application. However, transaction objects cannot be reused.
The application must check the return values of all the functions called. If all calls succeed, the application can vote to commit the transaction. This does not mean the transaction is committed; it only means that the application is ready to commit.
MS DTC now starts a two-phase commit protocol, asking each participating resource manager to prepare and to inform MS DTC whether it is ready to commit the transaction. If all the resource managers report that they are prepared to commit, MS DTC commits the transaction. If any resource manager fails to report that it is prepared to commit, MS DTC aborts the transaction.
All this activity by MS DTC is invisible to the transaction application. The application only sees the return value of the Commit function that it calls. When a successful Commit is returned to the application, the transaction is completed.
Note
When a transaction is completed, it does not mean the work is completed. When the transaction manager commits the transaction, it only means that each resource manager guarantees that it will do its part of the transaction at some later time.
Dead-letter queues can be used for both transactional and nontransactional messages (Message Queuing provides a separate dead-letter queue for transactional and nontransactional message). If there is a transactional type mismatch between messages and their destination queues, the messages are returned to their appropriate dead-letter queue under the following conditions.
If the properties of the destination queue can be accessed at send time, the send operation is rejected by the sending queue manager due to queue type and message type mismatch, and the messages are not sent to the dead-letter queue.
If the queue properties cannot be accessed at send time, such as when you are sending messages directly to a remote location, the send operation is rejected by the receiving queue manager and the messages is sent back to the dead-letter queue.
More Information
| For information on | See |
|---|---|
| A summary of functions, methods, and message properties that are used in transactions. | Transaction Functions, Methods, and Properties |
| Sending messages within a transaction | Sending Messages to a Transactional Queue |
| Retrieving messages within a transaction | Retrieving Messages from a Transactional Queue |
| How messages are placed in the queue | Ordering of Messages in a Transactional Queue |
| Checking transaction boundaries on a queue basis | Checking for Transaction Boundaries when Receiving Messages |
| Aborting transactions | Aborting the Transaction |