WCF WTF (part 2)

Here’s few things I learned the hard way, about WCF.

  • Say you’re using sessions and you have custom behavior on your service and your session. Your session doesn’t get committed and first (or any other) message in session gets delivered over and over (or no message get’s delivered at all) – i.e. it becomes a Poison Message. You have tracing turned on, but all it says is enigmatic ‘RequestContext aborted.’


The reason for that may be that your custom behavior throws an exception, that does get caught silently, but strangely, it does not show up in the trace log.

At least one operation on the ‘MyServiceWithConfiguration’ contract is configured with the TransactionFlowAttribute attribute set to Mandatory but the channel’s binding ‘MyBindingName’ is not configured with a TransactionFlowBindingElement. The TransactionFlowAttribute attribute set to Mandatory cannot be used without a TransactionFlowBindingElement.

As described here, by LeszekG netMsmqTransport does not use transaction flow to ensure that operations are performed atomically. You can set TransactionFlowAttribute.NotAllowed and your transaction will work perfectly fine.


  • This one is really obscure, and either I’m doing something completely wrong, or it’s a really misleading and plain wrong error message:


The actual problem seems to be that TransactionScopeRequired is set to false. Setting it to true, made the exception disappear, and the whole program worked. I’m still not sure however as to true reason for this, not validity of my solution. Can anyone explain this to me?

Technorati Tags:


Pawel Pabich says:

The questions is what is the point in using TransactionFlowAttribute(Mandatory) in a disconnected scenario? Long running transactions are in most cases dangerous and WCF might discourage you from using them. What is more in disconnected scenarios it might actually not be able to flow any transaction. But the last screenshot is certainly interesting :).