Public Property SupportsTransactedInbound As Boolean

public bool SupportsTransactedInbound { get; set; }

public:
property bool SupportsTransactedInbound {
    bool get ();
    void set (bool value);
}

/** @property */
public boolean get_SupportsTransactedInbound ()

/** @property */
public void set_SupportsTransactedInbound (boolean value)

public function get SupportsTransactedInbound () : boolean

public function set SupportsTransactedInbound (value : boolean)

Property Value

There are two ways to provide transaction support within the adapter inbound message exchange handler, dispatcher-initiated transactions and adapter-initiated transactions. If this setting is true, the transactions will be dispatcher-initiated; otherwise, the transactions will be adapter-initiated.

Dispatcher-initiated transactions

If this setting is set to true, the transactions will be initiated by the WCF dispatcher. Hence, they are called dispatcher-initiated transactions.

• The adapter developer's implementation for TryReceive method will always be called in the context of a transaction.

• If the host is not using the WCF dispatcher, but using channel level programming for pulling the messages, it should honor the TransactedReceiveEnabled on the WCF Binding and should all the Receive method of the IInputChannel interface or the ReceiveRequest method of the IReplyChannel in a transaction context.

• The Current in the IInboundHandler.TryReceive will be committed after the dispatcher dispatches the messages submitted by the adapter to the service implementation.

• WCF creates a new transaction for each IInputChannel.Receive call by default. Spanning a transaction across multiple receives is up to the service host and not determined by the adapter developer.

Adapter-initiated transactions

If this setting is set to false, the transactions need to be initiated by the adapter. In other words, before returning a message in IInboundHandler.TryReceive, you need to attach a transaction with the message by calling the Set method of the TransactionMessageProperty class. WCF dispatcher will first create a non-blocking (rollback) dependent clone from the transaction that the adapter developer sets on the message. Then it will dispatch the message to the service implementation.

• This type of transaction can only work with two-way messaging (e.g. Reply Channel) models 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 the transaction 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.

Development Platforms

Target Platforms