使用英语阅读

通过


获取通知

许多应用程序不需要为了接收或处理查询通知而包含代码。当 SqlDependency 对象管理通知订阅时,该对象会自动监视该订阅。通知消息到达后,SqlDependency 对象将调用在 SqlDependency 对象中注册的事件处理程序。使用此方法时,不需要执行特殊工作来接收通知。使用 SqlDependency 的应用程序不需要接收或处理通知消息。

但是,如果应用程序使用通知请求,则该应用程序必须监视队列,并对通知消息做出响应。在这种情况下,需要为接收通知的服务编写处理消息的应用程序。请求通知的应用程序可以是处理消息的应用程序,或者您也可以编写其他应用程序来接收并响应查询通知消息。

SQL Server 使用通知 ID 和已提交的实际查询的组合跟踪通知订阅。如果应用程序使用同一个通知 ID 请求两个不同查询的通知,SQL Server 将使用同一通知 ID 创建两个订阅。但是,如果应用程序使用同一个通知 ID 请求同一查询的通知两次,SQL Server 将使用第二个请求中指定的超时值创建一个订阅。

通常,数据库中运行的应用程序是消息到达后由队列激活的存储过程。这些存储过程可以使用 Transact-SQL 或 .NET 语言之一进行编写。较少使用的方法包括将应用程序作为计划作业运行,或使用启动任务在后台连续运行存储过程。

通常,在数据库外运行的应用程序使用下列方法之一接收消息:

  • 应用程序可以定期轮询队列来查看消息是否已到达。

  • 应用程序可以使用 RECEIVE 语句的 WAITFOR 子句来阻止对 RECEIVE 语句执行批处理或存储过程,直到该语句至少返回一行。

  • 应用程序可以为接收通知的队列上的 QUEUE_ACTIVATION 事件创建事件通知。然后,该应用程序可以使用上面两个策略之一监视接收激活事件的服务。

不太常用的方法包括使用 WMI 监视队列激活,或编写执行某些外部操作的公共语言运行时 (CLR) 存储过程以对消息做出响应。

由于查询通知对话始终包含单个通知消息,因此处理查询通知的应用程序必须在接收消息之后结束会话。否则,对话最终将超时。如果查询通知对话超时,则 SQL Server 会将对话超时错误记录在 SQL Server 错误日志中。

有关编写使用 Service Broker 的应用程序的详细信息,请参阅用 Service Broker 编程的优点。有关如何启动使用 Service Broker 的应用程序的详细信息,请参阅选择启动策略

请参阅

参考

概念