Digging around today I have found something that, at first seemed odd, but probably isn’t. When a message gets transmitted between service broker instances, it has an associated conversation ID. One might expect that the ID would travel with the message(s) to the destination instance. After all, it’s the conversation ID that ties together all the messages that need to be treated as one dialogue.
At the destination, however, the conversation ID that the messages have is different to the one they are associated with at the sending end.
This seems odd.
All the messages in a conversation at the receiving end have the same conversation ID, it’s just a different GUID to the one that they have in the source database.
Apply a bit of brain juice and I surmise that what is going on here is either (or both) of (a) the system just not trusting the sender GUID, so causing a new one to be used, (b) an incrementing GUID is being used for the conversation ID, so that the destination has to assign a fresh value so as to maintain the sequence order of the ID.
I need to do a bit of testing to see if (b) is in fact what’s going on here.
P.S. I shall be presenting a talk on Service Broker of the SQL Server User Group in Manchester in June.