Using MSMQ With MTS

In this example (called

Collector

) , we’re going to imagine that there’s a group of us that are fanatical collectors of something that people scour the planet for. Something that you can buy in the shop for a few dollars and can subsequently change hands for thousands. As those of you out there with young daughters may already have guessed, I’m talking about Beanie Babies here. We have two conflicting requirements here: obviously, we want to avoid getting duplicates, but in order to build our collection as quickly as possible, we have to spread our team of buyers across the whole globe. Eagle-eyed readers may have already spotted that this is the foreign exchange order-passing system that I described above, albeit disguised a little.

Fortunately, all our buyers are armed with networked Windows NT machines running SQL Server, and, of course, MTS and MSMQ. So how are we going to configure this?

Let’s say that each machine has a database containing a single table,

checklist

. This table has two fields: description
and wanted
. The first field is a varchar
key. The second is a bit
field, set up thus:

Key	Name	Datatype	Size	Default
	`description`	`varchar`	255
	`wanted`	`bit`	1	0 (true)

For the purposes of this demonstration, we’ll call the databases by the names of the computers themselves, in upper case. In turn, each server will access its local database through a SQL Server File DSN which we'll call

WPSamples

. Each database contains the items that the owner of that machine is currently looking for. There must be no duplication of items between databases, because that would mean that more than one buyer could be looking for the same Beanie Baby, and that’s the situation that we’re trying to avoid.

I won’t go into the details of setting up the databases, as I covered this in the Kidnap Game example in the previous chapter.

As well as these databases, we’ll need some queues. We’ll set up one public queue per machine, named

offered

. This queue will be used by our clients to offer items for other buyers to look for. At the end of each day, a buyer might dump all the items in his or her outstanding want list onto this queue. Interested buyers in other parts of the globe could then scan this queue and take off any items that they think they stand a good chance of getting hold of. We’ll make these queues transactional. Transactional messages can only be sent to transactional queues and non-transactional messages can only be sent to non-transactional queues (it is possible for a transactional queue to receive non-transactional messages from another local queue however). In general, the same holds for taking messages off queues, except that you can take a message off a transactional queue outside of a transaction, but only if it’s a local queue.

The main difference between transactional and non-transactional queues is their behavior when it comes to dead letter queues. If a non-transactional message fails to be delivered, it will be dumped into the dead letter queue on the machine that it had reached at the point when it failed - but only if the dead letter option was specified when the message was created. If a transactional message fails to get delivered, the message is always dumped into the transactional dead letter queue on the machine that it was originally sent from.

So what ingredients do we need to build one of these clients? Well, we need some straight, non-transactional database manipulation, some straight, non-transactional message queuing and some transactional stuff to transfer messages between database and queue (and vice versa).