SEND/RECEIVE And Message Order

I understand that SQL Service Broker will RECEIVE messages in the same order of SEND, so long as the messages are on the same conversation.



I would like to accomplish queue-level ordering instead of (or in addition to) conversation-level ordering.



There is a significant business case for this level of ordering. Consider an order processing system which is specified to fulfill orders in the sequence they are received. The reason for the ordering is as follows. Suppose the process(es) that RECEIVEs from the queue is down for several hours and the messages back up in the queue. Various customers place orders throughout this period of time. If more orders are placed than there are quantity for an item, the customers who placed their orders earliest in the day ought to be the ones that receive the merchandise and the later orders should be placed on backorder.



Limited experimentation showed that SQL Server totally disregards the order in which the messages were sent (on different conversations to the same queue).



The potential solution to use the same conversation has some drawbacks:

1. Difficult to do error handling because of the way error handling works in conversations.

2. It is not possible to RECEIVE using multiple threads. (Yes, RECEIVEing on multiple threads also would reorder the messages, but the reorderings would be localized in time so this would be tolerable by a lot of applications. In other words, orders from 1:00 AM would not be mixed with orders from 9:00 AM.)



Can anyone see a good solution to this in the current version?



If there are no good solutions, it would be great if Microsoft considers adding a feature where you can declare an ordering requirement when you CREATE QUEUE. Even support for an "approximate" ordering (messages can rearrange +/- several seconds) would be helpful, but the current way which seems to totally randomize the message order is not good for certain kinds of significant applications.