If you are planning to use message queuing, you should consider creating transac-tional message queues. Creating private queues is quick and easy, and despite Transactional being the only option in the dialog, it can be easy to disregard. Figure 10.7 shows the very lean dialog where you have the opportunity to check Transactional.
Figure 10.7 Messaging Queue Creation Dialog
When message queues are used as transactional, they guarantee that all messages sent within the transaction, if they can be delivered, will arrive exactly once, and in the order in which they were sent. If one of the operations fails, the transaction is aborted and changes are rolled back to the state when the transaction was invoked.Therefore, for data reliability, you would choose to use transactional queues.
Similarly, if you plan to implement a message queue in an Orchestration transaction, the queue will need to be transactional.When using transaction shapes in orchestration, their transactional properties are dependent on the components implemented. If you have designed a transaction in Orchestration, and a port within that transaction implements a nontransactional message queue, you in fact do not have a transaction.The queue (as well as the other implemented components) must be transactional for the XLANG schedule to implement transactions.
So, why would you not choose transactional message queues? One reason could be that transactional message queues must be local queues on the BizTalk Server. If your application requires the use of remote queues, transactional will not be an option. Another reason could be that transactional message queues require more resources, so if performance were a driving factor, you would need to consider nontransactional message queues.
Was this article helpful?