none
conversation groups and processing in order on the target end

    Question

  • Is there any way to ensure that messages sent on different dialogs have the same conversation group id on the target queue?  I was attempting to set the conversation group id on the dialog before sending but learned that this only works on the initator end.  

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=174976&SiteID=1

    I have messages that could be sent from different applications (and at slightly different times) that need to processed exclusively (i.e. have the same conversation group id).


    Sunday, December 25, 2005 8:57 AM

Answers

  • You can also add an extra message to your conversation. This message is sent first and contains some form of tag or Id based on which when the target receives this first message, it moves the target conversation endpoint into an appropiate group.

    So the initiator does normal BEGIN DIALOG, followed by two SEND (one for the tag/id and one for the real payload). The target receives messages normally in a loop, but reacts differently to the two message types:
    - if the message is a tag/id message, it finds the appropiate group and moves the conversation into that group
    - if the message is normal payload it process it normally, assured that is the only one processing this group

    HTH,
    ~ Remus

    Wednesday, December 28, 2005 6:43 PM

All replies

  • Message ordering is guaranteed within a conversation. Is there any reason that stops you from sending all messages on the same conversation?

    HTH,
    ~ Remus

    Sunday, December 25, 2005 9:12 AM
  • Thanks for the reply - Yes, the sending of messages will be distributed and at different times.  i.e. 3 different applications will send messages to the same queue.  The messages have to be processed exclusively  I tried using one queue as both the initiator and target but the converation group IDs were still different.  The move conversation command works but only after messages have been received at the target queue.
    Sunday, December 25, 2005 9:19 AM
  • Having the conversation from one queue to the same queue does not help, as you noticed, the initiator and target conversation don't share the conversation group. The behavior of conversations that are with local (or event the same) service/queues is in every respect the same as conversations that are with remote services/queues.

    But in general, trying to use the conversation group to achieve ordering will get you nowhere. Conversation groups only control what messages can be received by a transaction. That is, they're only relevant to locking. Even if you manage to move all three conversations into the same group and all three messages will be present in the queue, the RECEIVE verb will return them in random order! The messages are guaranteed to be in order within a conversation, not within a group. Actually, you can check the RECEIVE verb execution query plan in the SQL Management Studio and you'll see that it has an ORDER BY clause. This will sort the resultset (a.k.a the messages received) by conversation_handle (among other columns), which is a GUID, so basically the order of conversations within a group is random.

    The only way to achieve order is to use one single conversation and send all messages on it. It doesn't matter if they are sent at different times, they will be RECEIVEd in the order sent.

    The very problem of preserving order between 3 messages sent from 3 distributed locations is, in my opinion, unsolvable. 3 distributed locations means 3 distinct local times. Which is the authoritative time between them? I.e. if message 'two' was sent one minute after message 'one', but the time on location 'two' is two minutes behind, which message should be considered as sent first? Or if 2 of the 3 messages are sent at identical time 05:10:00 AM, which one was sent first? Or what if message one was sent fine, but the machine hosting location two was destroyed by a suden burst of cosmic rays just before message 'two' being sent, and then message 'three' was sent fine, is message 'three' really message 'three' or is message 'two'?
    I only see this problem resolvable if the messages are sent using a primitive that serializes the messages (i.e. the conversation).

    Also keep in mind that even if you achieve order by using a single conversation, you still won't be guaranteed that you'll RECEIVE all 3 messages at once (in one single RECEIVE resultset). Messages are RECEIVEd as they show up in the queue, so is perfetcly possible to RECEIVE message 'one' and 'two' while message 'three' is still in traffic.

    If you can give some more details on what are you trying to do, I feel we can probably think of a way to achieve what you need.

    HTH,
    ~ Remus

    Sunday, December 25, 2005 1:40 PM
  • Thanks again for the quick reply

    I think I may have phrased the problem incorrectly.  I only need the messages in a single conversation to be ordered, but I need for the messages in the three different conversations to be processed exclusively (The processing of the messages will be distributed as well).  Unfortunately I cannot send all the messages in a single conversation, so I though I could just designate them to a single conversation group so that only one message from any of the three conversations could be processed at one time.

    Any suggestions?

     

     

     

     

    Sunday, December 25, 2005 5:41 PM
  • You can put the three dialogs in the same conversation group but you will need to do it at the target end when you receive the messages - using MOVE CONVERSATION.  I don't know of a practical way to do this.  I generally send messages out on different dialogs in the same conversation group so the responses are received together.  For example, you could have one of your dialogs send a message to the target and when you receive the message on the target queue, open two new dialogs in the same conversation group as the received message and have those two dialogs send out request messages to get the data back.  Pretty convoluted but it should work. 
    Monday, December 26, 2005 11:26 PM
  • You can also add an extra message to your conversation. This message is sent first and contains some form of tag or Id based on which when the target receives this first message, it moves the target conversation endpoint into an appropiate group.

    So the initiator does normal BEGIN DIALOG, followed by two SEND (one for the tag/id and one for the real payload). The target receives messages normally in a loop, but reacts differently to the two message types:
    - if the message is a tag/id message, it finds the appropiate group and moves the conversation into that group
    - if the message is normal payload it process it normally, assured that is the only one processing this group

    HTH,
    ~ Remus

    Wednesday, December 28, 2005 6:43 PM