Transaction support in inbound message exchange handler

  • Article

**

Scenario: How does WCF LOB Adapter SDK enable transaction support in the inbound message exchange handler?

 

There are two ways of providing transaction support within the adapter inbound message exchange handler.

 

 

 

Transactions initiated by dispatcher

 

Set Microsoft.ServiceModel.Channels.Common.AdapterSettings::Messaging::SupportsTransactedInbound to true.

Details

 

· Your implementation for IInboundHandler::TryReceive() will always be called in a context of a transaction i.e. Transaction.Current will have value.

· If the host is not using the WCF Dispatcher – Service Host – and using Channel Level Programming for pulling the messages, it should honor the System.ServiceModel.Channels.ITransactedBindingElement::TransactedReceiveEnabled on the WCF Binding and should call the IInputChannel::Receive() or IReplyChannel::Receive() in a transaction context if the above value is true.

· The Transaction.Current you get in the IInboundHandler::TryReceive() will be committed after the dispatcher dispatches the message you submitted to the service implementation.

· If the channel is a Reply channel, the reply sent to the adapter on the IInboundReply::Reply() will not be in the context of the transaction.

· WCF creates a new Tx for each IInputChannel / IReplyChannel Receive() call by default. Spanning a Tx across multiple receives is up to the Service Host and not determined by the Adapter Developer.

Transactions initiated by adapter

 

Set AdapterSettings::Messaging::SupportsTransactedInbound to false. Before returning a message in IInboundHandler::TryReceive() attach a Tx with the message by calling System.ServiceModel.Channels::TransactionMessageProperty.Set(Tx, message)

Details

 

· WCF Dispatcher will create a non-blocking (rollback) dependent clone from the transaction you set on the message and dispatch the message to the Service Implementation

· This type of transaction can only work with two-way messaging (Reply Channel) model because the adapter has to wait for the reply message to come from the Service Implementation before the adapter can commit the original transaction to make sure that the dependent transaction created by the dispatcher has been completed. If the adapter tried to commit it before the dependent transaction is completed (i.e. dispatched to the service), it will directly abort.

· You can have one transaction and set it to the multiple messages (and dependent clones will be created for each message by the Dispatcher).