SQL Queue Service Broker Application

Question

I'm designing an application that will be reading messages from an SQL Queue. This is a requirement. I must use their queue. The problem is how to read their queue. I would like to use it just like an MSMQ but it doesn't look possible. I need to read messages in FIFO order one at a time. To read one at a time I would have to make each message a conversation but then they would not necessarily be in FIFO order. I can use one never ending conversation to maintain order but then I believe I have to read everything in the queue. Not just one message. Has anyone built an application to perform the way I need it to? Is it impossible? Any other suggestions?

Thanks in advance.

Answer 1

reading messages from an SQL Queue. This is a requirement... I would like to use it just like an MSMQ but it doesn't look possible. I need to read messages in FIFO order one at a time.

My advice is to not to try to fit a square peg in a round hole. If using Service Broker is a requirement, then do not try to fit on top your programming model. Educate yourself a little bit about Service Broker programming and try to design something that leverages SSB strengths. Read these links before you plow ahead:

• Conversation Group Locks
• Service Broker Activation
• Writing Service Broker Procedures
• Reusing Conversations

Go ahead, I'll wait...

I hope by now it is clear that there is a way to do what you originally asked: SSB offers Exactly Once In Order delivery within a conversation so you can achieve FIFO only by sending all messages on a single conversation. SSB also allows you to restrict the dequeue to only one message using RECEIVE TOP(1) ... FROM ... . Combine these two and you get exactly what you asked for.

But this is not how an SSB application should be designed. There is literally no reason to restrict dequeue to a single message, you should dequeue a batch and process the batch in loop. Keep it one transaction and the result is indistinguishable from dequeueing one-at-a-time. Next, the FIFO requirement can only make sense within a conversation, as soon as you have multiple senders FIFO cannot exists, as a fundamental concept (what does 'First' mean when multiple senders are concurrently sending messages? 'First' to hit the target queue, in a random network roulette?). You may get an illusion of FIFO by dequeing in the order messages arrive, and actually SSB does exactly that. The naive 'global FIFO' concept crumbles as soon as you consider concurrent processing. Throw in rollbacks and retries as a spice.