In BizTalk Server 2006 R2, when the WCF-Custom adapter was used with any binding, the WCF-Adapter would try to determine, at runtime, whether a System.Transactions TransactionScope was required when sending a message over a channel. This involved the following:

• If an out-of-box binding was used, then most of those bindings have a Transactions property. We would look at that to determine whether the property value was true or false.
• If a custom binding was used (either WCF's CustomBinding, or your own binding), we would get the binding elements from the stack, and see if certain binding elements were present, which we know control transaction flow. Based on the configuration of those binding elements, we would determine whether a transaction was required or not.
• If we couldn't figure out what to do, we would just play safe and use a TransactionScope.

NOTE that in the above three steps, step 2 is expensive for dynamic send ports, since for dynamic send ports, we would execute that step every time, and calling CreateBindingElements() multiple times can add up.

In BizTalk 2009, we went ahead and added two properties on the port - "EnableTransaction" and "IsolationLevel". If we find the EnableTransaction property set on the message, then we know whether to use a TransactionScope or not, and hence we don't need to execute those three steps above. However, if we don't find this message context property, then we fall back to the previous behavior.

Hence, for performance, when using dynamic send ports with the WCF-Custom adapter, when setting the context properties for BindingName and BindingType (amongst others), also set the EnableTransaction and IsolationLevel message context properties.