Some MSMQT Mechanics

October 19, 2004

This thread in the Biztalk.General newsgroup</a> explains some of the dynamics behind MSMQT operation and also makes clear why the active/dehydrated instances of MSMQT receive locations stay in the HAT tool once all orchestrations and messaging instances have finished with it. To quote the important part in this regard:

Second, InReleaseT. Because MSMQT needs to guarantee ordered delivery, at
any point in time only one thread on only one computer in the group must
process messages that are delivered to a specific queue. This thread works
on some persistent data that is saved and loaded from the database. We call
this a MSMQT instance. When the thread is running on a specific computer,
we say that the MSMQT instance is “Active”. When the data is persisted in
the database and there is no one working on it we say that the instance is
“Dehydrated”. An active MSMQT instance maintains a lock on the queue object
in the database, so that no other active instance on any other computer can
work on this queue. For load-balancing purposes and to save memory, active
MSMQT instances are dehydrated if the queue wasn’t used in a while.

Good to note this information comes straight from the horses mouth.