Messaging is not a Transaction

What happens to the messages being transmitted and any unprocessed messages when I call Abort? Do those messages get delivered or do they get discarded?

Once you call Abort, the state of any of the network resources involved becomes undefined. What happens to any lingering messages is implementation-dependent and subject to a large number of timing issues. For example, you may call Abort on the client but the server is blissfully unaware that anything has happened until it tries to read additional messages past the ones it has queued up. Or, you may call Abort on the client and that termination notice races ahead of any data on the wire. Aborting the connection may cause messages to be discarded that were completely received by the server machine but not yet sent to a channel. You have no way of knowing because your connection is gone.

If you need some kind of well-defined behavior, then you should be looking at application protocols, reliable messaging, or transactions to give you a more specific guarantee about what occurs during a failure. Transactions are generally the easiest way to get a very precisely defined failure model, but you may find that a simple application protocol, like resending messages and rejecting duplicates on the server, is good enough to solve your problem. What these methods have in common is that they can carry some state around past the lifetime of that connection you just killed.

Next time: What a Binary Encoding Means

Comments

• Anonymous
  April 05, 2007
  In the past I've talked a lot about the absolute minimum you need to do to write a working channel. However,