有人可以解释服务代理中的对话组吗？
目前，我正在使用服务代理将消息从一台 SQL 服务器发送到另一台。在发送服务器上，我尝试关联消息，以便它们在接收端串行处理。根据文档，会话组似乎非常适合此目的，但在接收服务器上，消息被分配到与我发送消息时指定的会话组不同的会话组。
我在网上进行了搜索，发现这种行为似乎是有意为之的（http://social.msdn.microsoft.com/forums/en-US/sqlservicebroker/thread/baf48074-6804-43ab-844a-cb28a6dce02b/），但是然后我对 (http://msdn. microsoft.com/en-us/library/ms178624.aspx)
WAITFOR(
GET CONVERSATION GROUP @conversation_group_id FROM [dbo].[ReceiveQueue]
)
如果对话组未收到来自发件人的邮件，并且使用相同对话组 ID 发送的邮件没有相同的对话组id 在接收端，上面的代码有什么意义？
Can someone explain conversation groups in service broker?
Currently, I'm using service broker to send messages from one SQL server to another. On the sending server, I'm trying to correlate the messages so they are processed in serial on the receiving side. Based on the documentation, conversation groups seem to be a perfect fit for this, but on the receiving server, the messages get assigned to a different conversation group from the one I specified when sending the message.
I've search around the web and saw that this behavior seems to be intended (http://social.msdn.microsoft.com/forums/en-US/sqlservicebroker/thread/baf48074-6804-43ab-844a-cb28a6dce02b/), but then I'm confused about the usefulness of the syntax from (http://msdn.microsoft.com/en-us/library/ms178624.aspx)
WAITFOR(
GET CONVERSATION GROUP @conversation_group_id FROM [dbo].[ReceiveQueue]
)
If the conversation group doesn't come across with the message from the sender and messages sent with the same conversation group id don't have the same conversation group id on the receive side, what's the point of the code above?
发布评论
评论（1）
会话组是用于锁定的本地原语。会话组内的消息没有顺序保证，并且会话组不会通过网络传输。
会话中的消息顺序由 Service Broker 保证。因此，为了保留处理中相关消息的顺序，请在同一对话中发送它们。
需要对话组来对一组彼此相关的对话进行分组。
GET CONVERSATION GROUP和RECEIVE动词都保证它们将锁定整个会话组，从而防止任何其他线程处理相关消息。例如，考虑一个旅游网站。它收到一条请求预订假期套餐的消息。因此，它发起与酒店预订服务的对话并发送预订房间的请求，它发起与航空预订服务的对话并请求旅行预订，它发起与汽车租赁代理服务的对话并请求汽车预订。它创建的这三个新会话都与接收请求的初始会话位于同一组中（应用程序使用了 WITH RELATED_CONVERSATION 子句）。 microsoft.com/en-us/library/ms187377.aspx" rel="noreferrer">开始对话 在所有三个上）。然后它提交并继续处理队列中的消息。随后，这 3 个相关请求的响应开始出现，时间几乎是随机的。假设酒店的响应是第一位的。该消息被应用程序接收，并继续使用酒店的响应来更新请求的状态。与此同时，航空公司响应进来。如果允许另一个线程接载它，它会尝试更新同一请求的状态，从而导致阻塞甚至死锁正在处理酒店响应的线程。当酒店响应被处理时，线程提交并因此解锁整个对话组，允许任何线程（包括其本身）获取航空公司响应并处理它。Conversation groups are a local primitve used for locking. Messages within a conversation group have no order guarantees, and conversation groups do not flow across the wire.
The message order is guaranteed by Service Broker within a conversation. So to preserve the order of corrleated messages in processing, send them on the same conversation.
Conversation groups are needed for groupping a set of conversations that are related to each other. Both
GET CONVERSATION GROUPandRECEIVEverbs guarantee that they will lock an entire converstaion group, thus preventing any other thread from processing related messages. For example consider a traveling site. It receives a message with a request to book a holiday package. As a result it initiates a conversation with a hotel booking service and sends a request to reserve a room, it initiates a conversation with an airline reservation service and asks for travel reservation, it initiates a conversation with a car rental agency service and asks for a car reservation. These three new conversation it created are all in the same group with the initial conversation that the request was received on (the application has used theWITH RELATED_CONVERSATIONclause of BEGIN DIALOG on all 3 of them). It then commits and proceed to process the messages in the queue. Later responses from these 3 correlated requests start comming in, at pretty much random times. Say the hotel resposnse comes in first. The message gets picked up by the applicaiton and it goes ahead to update the status of the request with the response from the hotel. At the same time, the airline response comes in. If another thread would be allowed to pick it up, it would try to update the status of the same request, thus resulting in blocking or even deadlock against the thread that is processing the hotel response. When the hotel response is processed, the thread commits and thus unlocks the whole conversation group, allowing for any thread (including itself) to pick up the airline response and process it.