构建使用异步通信的分布式应用程序的基础之一可以表示为不要主动等待任何事件!这样,基于Service的自然解决方案就是通过到达队列的消息来激活存储过程。
官方Microsoft教程中的第2课:创建内部激活过程展示了如何将存储过程绑定到消息队列。它还建议了如何实现sp。
(我对SQL很陌生。但是,难道不应该在BEGIN之后再出现一个CREATE PROCEDURE... AS,在GO之前再多一个END吗?)
我能理解吗?看看我下面的问题..。
CREATE PROCEDURE TargetActivProc
AS
DECLARE @RecvReqDlgHandle UNIQUEIDENTIFIER;
DECLARE @RecvReqMsg NVARCHAR(100);
DECLARE @RecvReqMsgName sysname;
WHILE (1=1)
BEGIN
BEGIN TRANSACTION;
WAITFOR
( RECEIVE TOP(1)
@RecvReqDlgHandle = conversation_handle,
@RecvReqMsg = message_body,
@RecvReqMsgName = message_type_name
FROM TargetQueueIntAct
), TIMEOUT 5000;
IF (@@ROWCOUNT = 0)
BEGIN
ROLLBACK TRANSACTION;
BREAK;
END
IF @RecvReqMsgName =
N'//AWDB/InternalAct/RequestMessage'
BEGIN
DECLARE @ReplyMsg NVARCHAR(100);
SELECT @ReplyMsg =
N'<ReplyMsg>Message for Initiator service.</ReplyMsg>';
SEND ON CONVERSATION @RecvReqDlgHandle
MESSAGE TYPE
[//AWDB/InternalAct/ReplyMessage]
(@ReplyMsg);
END
ELSE IF @RecvReqMsgName =
N'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @RecvReqDlgHandle;
END
ELSE IF @RecvReqMsgName =
N'http://schemas.microsoft.com/SQL/ServiceBroker/Error'
BEGIN
END CONVERSATION @RecvReqDlgHandle;
END
COMMIT TRANSACTION;
END
GO当消息到达时,将调用该过程,并进入“无限”循环。实际上,循环并不是无限的,因为当没有数据到达时(在BREAK之后),ROLLBACK之后的是TIMEOUT。
如果数据到达,则跳过BREAK。如果预期的消息到达,则回复将被发回。如果接收到...EndDialog或...Error消息,则执行END CONVERSATION。这里还能看到其他信息吗?
当一些消息到达(并被处理)时,事务就会被执行。
但是为什么现在要循环呢?是否打算处理因过去通信线路中断而陷入队列中的其他消息?还是因为一次收到更多的消息而不能这么快地处理?
当另一条消息排队,而存储过程仍在运行时,会发生什么?是否为其处理指定了另一个工作流程?另一个存储过程能并行启动吗?如果是,那为什么是循环?
谢谢你的帮助,佩尔
发布于 2012-08-13 15:04:22
内部激活不像触发器。具体而言,激活的过程不会针对到达的每一条消息启动。相反,当有需要处理的内容时启动该过程,并在SSB基础结构监视进度时(在一个循环中)连续地对消息进行排队列,并在必要时启动第二个过程,以帮助达到指定的最大值。见理解队列监视器。
在激活的过程中有一个循环并不是严格的要求,事情应该工作的很好,甚至w/o循环。在非常繁忙的环境中,循环应该表现得更好。还有这个旧的MSDN讨论。
https://stackoverflow.com/questions/11936814
复制相似问题