Stop Losing Data in Production

All systems that make use of HTTP for their incoming communication are exposed to this issue.

While HTTP does provide for a very interoperable communication layer, holding this channel open during all message processing increases the window of time in which the system is exposed to data loss. Unfortunately, the most important business logic usually takes the longest to run.

These problems are most pronounced when the system is under load. Then a single web server crashing can leave many connections open and transactions pending. This may cause the database's connection pool to run out thus not being able to serve new requests, resulting in an exception. Also, all of these pending transactions increase the likelihood of a deadlock occuring in the database, resulting in even more exceptions.

The industry standard "best practice" to handle these exceptions is to log that they occurred, and then to, in effect, discard the request with all the valuable data it contained.

Queuing Helps

To address the above issues, some developers have turned to reliable messaging like that found in MSMQ and plugged into WCF via the NetMsmqBinding. While this is a good first step, many don't know that the NetMsmqBinding does not write messages to disk by default, nor does it make use of transactional queues by default. This leaves the system just as exposed as before.

The Difference With NServiceBus

NServiceBus takes care of all the little things that need to be set up.

By automatically creating transactional queues, using the right type of transaction type (automatic, not single), enlisting into the distributed transaction coordinator (DTC), and providing an automatic retry mechanism to get past transient exceptions like deadlocks and connection pool draining, the valuable data coming in to your system doesn't get lost.

Even when a message fails the maximum number of times, NServiceBus does not discard it. Instead the message is moved to a different queue. WCF can be configured to do this as well - NServiceBus does it by default. Also, NServiceBus allows you to pull all failed messages to a central queue on a single machine - WCF puts the message in a subqueue on the original machine making monitoring much more difficult.

NServiceBus also includes a tool to enable administrators to automatically return messages to their processing queues once they've resolved the issue that caused the errors. WCF has no such tool.

If you'd like to see a recorded webcast covering all of this information, the creator of NServiceBus - Udi Dahan, gave a presentation on these topics at Microsoft TechEd North America 2010.

Watch the webcast (opens a new window).

Next Steps