I've come across a strange behaviour in T-SQL script I have written and which I can recreate with the Service Broker Tutorial athttp://technet.microsoft.com/en-us/library/cc281528(v=sql.105).aspx where I have modified the code to dump Initiator and Target queue contents to a separate table (together with a timestamp and description of where in the code the dump occurs) so I can examine their contents at leisure. Code can be provided if needed..
Discussing the tutorial (which still applies to my script as well):-
1. Initiator begins dialog and sends a meassage. This populates the Target queue.
2. Stored procedure fires and executes as a result of the Target queue being populated.
3. Stored procedure execution - receives the message (Target queue now contains no rows).
4. Stored procedure execution - determines correct message type and sends a message which populates the Initiator queue.
5. The row is held in the Initiator Queue until we 'Receive' it.
Everything is fine and is as expected. However, here is the wrap...
At step 4, at exactly the same time the Initiator queue is populated, the stored procedure fires and executes again (with a different SPID). Don't forget, we haven't Received the message from the Initiator queue yet and is not as a result of intitiator 'ending conversation'. In fact, at this time the Target queue is empty and the check in the stored procedure for 0 row count when 'Receiving' from the queue prevents further messages being sent from the stored procedure.
Is this normal behaviour that the stored procedure executes whenever EITHER queue is populated even though we have defined only the Target queue as the internal activator?