Five Pitfalls of the Channel Model, Part 1

Although the WCF channel model has a relatively simple set of APIs, it has a very subtle set of rules for using those APIs.  I've picked out a small collection of rules to talk about for the next two posts.  You might have seen some of these before if you're a regular reader, but everything here is worth saying at least twice.  I may run follow-ups in the future to collect more rules as we come across them.  There is no shortage of wrong ways to use the channel model.

Pitfall #1: There's always a limit, even if no one tells you what it is

This is the best pitfall to employ when you need a mysteriously bad experience at random intervals.  Every operation has some threshold for timeliness, above which you'll start incurring user unhappiness.  Sometimes you know what that threshold is, although frequently you'll just have to guess.  The timeout model in WCF is that the threshold you set for an operation bubbles down to its suboperations so that they know how much time is remaining.  For various reasons, not every method allows you to specify a timeout.  That doesn't mean you have an unlimited amount of time.  Since you don't know how much time you can afford to spend, that means you must never take an appreciable amount of time to complete an operation without a timeout.

Pitfall #2: Clean up your toys when you're done

Most of the channel model has an explicit cleanup arrangement through the Close method.  An IDisposable implementation is often provided as a synonym for Close so that you can take advantage of the using syntax in C# to define a containment block.  It is a bad idea to not close an object after you're done.  At the level of the channel model, we don't promise to clean up after you.  Failing to call Close can lead to leaks of both memory and network resources, such as ports, namespaces, and available connections, for significant periods of time.  Don't let this happen to you.

Pitfall #3: If you break a message, you've bought it

A message is one of those objects that have an explicit cleanup requirement.  The difference between messages and things like channels is that messages are far more likely to be passed around.  There is one, and only one, owner for each message.  When a message is passed through a function, there should be some indication of whether ownership of the message has also been handed off.  Typically, giving away a message is equivalent to giving away its ownership.  The person that received the message will then either pass the message on to someone else or break the message open to read its contents.  Once you break open a message, you're pretty much stuck cleaning it up because you can't pass it on.

Next time: Five Pitfalls of the Channel Model, Part 2