Sql Server Service Broker对话组

Bri*_*den 7 sql-server service-broker

有人可以解释服务经纪人中的对话组吗?

目前,我正在使用服务代理将消息从一个SQL服务器发送到另一个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]
)
Run Code Online (Sandbox Code Playgroud)

如果会话组没有遇到来自发件人的邮件,并且使用相同会话组ID发送的邮件在接收方没有相同的会话组ID,那么上面代码的重点是什么?

Rem*_*anu 21

会话组是用于锁定的本地原始组.会话组内的消息没有订单保证,并且会话组不会通过网络流动.

消息顺序由对话中的Service Broker保证.因此,为了在处理过程中保留corrleated消息的顺序,请在同一个对话中发送它们.

需要使用会话组来填充彼此相关的一组会话.两者GET CONVERSATION GROUPRECEIVE动词都保证它们将锁定整个转换组,从而阻止任何其他线程处理相关消息.例如,考虑旅行网站.它会收到一条消息,其中包含预订假期套餐的请求.因此,它启动与酒店预订服务的对话并发送预订房间的请求,它启动与航空公司预订服务的对话并要求旅行预订,它启动与汽车租赁代理服务的对话并要求汽车预订.它创建的这三个新对话都与收到请求的初始对话在同一组中(应用程序在所有3个对象上使用了BEGIN DIALOGWITH RELATED_CONVERSATION子句).然后它提交并继续处理队列中的消息.来自这3个相关请求的后续响应开始在几乎随机的时间进入.说酒店的resposnse先进来.该消息被应用程序接收,并继续使用酒店的响应更新请求的状态.同时,航空公司的响应进来.如果允许另一个线程接收它,它将尝试更新同一请求的状态,从而导致阻止甚至死锁处理酒店响应的线程.当处理酒店响应时,线程提交并因此解锁整个会话组,允许任何线程(包括其自身)接收航空公司响应并处理它.

  • 目标可以使用MOVE CONVERSATION对对话进行分组.然后它可以将任何"新"对话移动到其正确的组中.另一种方法是反转对话框initiaton:'后端'启动对话框(因此控制他们在他身边的分组),'前端'发送对话框的*target*端点.如果后端无法知道前端名称/位置,则前端可以触发"发起",发送含义为"请在此地址订阅我"的消息.正确的解决方案取决于您的方案的具体情况.传一个电子邮件给我. (3认同)
  • 确实,MOVE有可能陷入僵局.感谢在分析过程中看到这一点.我有点担心你打算使用GET CONVERSATION GROUP而不是直接RECEIVE.GET存在的唯一原因是在组值/ RECEIVE WHERE组上放置模式GET GROUP/lookup状态,但坦率地说,我认为它没什么用处,我实际上后悔GET CONVERSATION被允许进入语言.像RECEIVE NO WHERE/lookup状态/进程这样的模式就像编码一样容易,而且实际上效率更高. (3认同)