Conversation Groups

I'm having some troubles with conversation groups. I need to send two messages on the same conversation group so I have the following in my SP....

BEGIN DIALOG CONVERSATION @.providerConversationHandle
FROM SERVICE [ProviderDataService]
TO SERVICE 'CalculatedDataService'
ON CONTRACT [ProviderDataContract]
WITH ENCRYPTION = OFF
, LIFETIME = 600;

BEGIN DIALOG CONVERSATION @.curveConversationHandle
FROM SERVICE [ProviderDataService]
TO SERVICE 'CalculatedDataService'
ON CONTRACT [ProviderDataContract]
WITH RELATED_CONVERSATION = @.providerConversationHandle
, ENCRYPTION = OFF
, LIFETIME = 600;

SEND ON CONVERSATION @.providerConversationHandle
MESSAGE TYPE [ProviderDataMessage] ( @.providerMessage );

SEND ON CONVERSATION @.curveConversationHandle
MESSAGE TYPE [ProviderCurveMessage] ( @.curveMessage );

When I query the queue I see two messages, but they don't have the same conversation_group_id.

Any ideas?

Thanks.

Hello Ian,

The conversation group is a locking primitive. Conversations in the same group are locked together, so that any transaction is guaranteed that is the only transaction processing messages on the current group.

As such, conversation groups are pertinent only for the site declaring the group. The group information does not travel with the message to the far side. The two conversations are related, but only in the SENDER's side. If you actually send back a reply on each dialog, then the replies will have the same conversation_group_id.

If the receiver wants to group dialogs, it can use MOVE CONVERSATION to do it, based on it's own locking policies.

Typically apps receive a message and begin new dialogs related to the dialog on which the message was received, not starting two new related dialogs (of course, the can be valid scenarios on for the later case as well!).

HTH,

~ Remus

|||

Thanks for the information.

So if I read you right conversation groups don't allow the receiver to "group" messages together. Are there any good pieces of sample code that show conversation groups in action? all I have seen so far are repeats of the BOL examples.

In my scenario I have two related messages and it is important that the receiving end of the dialog can retrieve and process both my messages together - so how would I go about achieving this?

Thanks

Ian

|||

You should send them both on the same dialog, instead of beginning separate dialogs for each message.

Note that this will allow the message to be received together, but will not guarantee it. The receiver service can still see only the first message while the second is still in traffic.

From my understanding of you example, what you actually looking for is to send 2 parameters to a calculationservice, right? And I assume the 'CalculateDataService' needs both of these parameters to do the actual calculation.

The easiest solution is to group both parameters on one single message and send one message instead of two. The XML and XPath support in the server make both composing the one message from two parts and retrieveing the separate parts on the receiver side easy, if you parameter values can be converted to text (xml nodes).

Often is the case that the two parameters are not available at the same moment, so the sender would prefer to send them separately. In this case you must have a state on the receiver. A table that uses the conversation_group_id as the key and stores the received @.providerMessage and/or @.curveMessage parameters. When the first message is received, the parameter (whichever is) is stored on the table. When the second message is received, the service will find the first parameter in the table and can now do the calculation and respond to the sender.

HTH,

~ Remus

|||

Thanks for the suggestions.

I want to keep my messages seperate as they are pretty large and I don't want the performance overhead of joining and spliting the data, so I guess I will have to look into your suggestions regarding state.

Thanks again.

Ian

|||

Hi Remus

Can you get this explained in BOL.

I couldn't find anything that explained that conversation groups only apply to the initiator side of the dialog. This does seem to be a recurring question

Cheers

|||

That's not in BOL because it's not true. Conversation groups can apply to either the initiator or the target or both. The issue here is that a conversation group is limited to a single queue. The means you can put conversations into a conversation group on the initiator but the conversation group id is not sent over the network to the target. You can also put conversations into a conversation group on the target queue also but this is independent of any conversation groups that you may have set up on the initiator. The conversation group is primarily used for a locking context for SSB commands. SEND and RECEIVE commands can't span queues in a single command so a lock that locks conversations on two different queues doesn't make sense.

Conversation groups aren't sent along with messages from the initiator to target becausethere's no way for the sender of the message to know whether the targets of the conversations in the group are in the same queue. In fact the destination queues can be changed around by the deployer so in general, the conversation initiator has no knowledge of the queue configuration of the target.

|||

Ok so I'm new to SB and what I got from BOL was that

1. conversation groups can be used to group conversations.

2. the conversation group can be specified in the begin dialog so conversations don't have to be intiated at the same time

What isn't in BOL is that even if you group conversations on the initiator, they can not be received from the queue of the target service in these groups.

This was what I was expecting. To be able to send messages from triggers to a service, and then use the RECEIVE TOP (x) to take x of these messages off the target queue and process them. However what it seems is that the RECEIVE statement only returns a conversation and so I have to do the RECEIVE statement x times to get a the BULK set of messages to process.

As has been mentioned when repsonses errors come back to the Initiator queue I can use 1 RECEIVE statement to get a bulk set of messages.

I hope that clarifies the confusion I fell into that I would like in BOL, unless I am wrong again (more than likely).

|||If you want to be anle to receive a bunch of messages at a time on the target side, you should put them into the same dialog. This not only allows you to get the efficiencies related to receiving multiple messages at a time, it also reduces the number of dialogs used and this has very positive performance benefits also. The down side is that all the messages will have to be processed on a single thread but that's the same behavior you would have gotten if you put all the dialogs into the same conversation group because the conversation group is locked when a message is received on any dialog in the group. If you want three threads to receive messages then you need three dialogs. There's a bigger discussion of this here: http://blogs.msdn.com/rogerwolterblog/archive/2006/05/20/602938.aspx