ADO.NET 2.0中的查询通知(2)

SQL Server 2005中的查询通知

在服务器一级，SQL Server分批处理客户端发送的查询。每个查询（可以将查询看作是SqlCommand.CommandText属性）只能包含一个批，尽管每个批可以包含多个T-SQL语句。SqlCommand还可以执行存储过程或者用户定义的函数，这些对象也可以包含多个T-SQL语句。在SQL Server 2005中，客户端发送的查询中还包含了其它三条信息：用于投递通知的Service Broker的service、通知标识符（一个字符串）、以及通知的超时值。如果查询请求中存在这三条信息并且查询包含了SELECT或者EXECUTE语句，那么SQL Server将“监视”该查询产生的所有结果集是否因为其他SQL Server会话而改变。如果产生了多个结果集，例如执行了某个存储过程，那么SQL Server将“监视”所有的结果集。

那么我所说的“监视”结果集是指什么？SQL Server又是如何完成该任务的呢？对结果集的变更检测是SQL Server数据库引擎的一部分，使用了SQL Server 2000中用于索引视图同步的变更检测机制。在SQL Server 2000中，Microsoft引入了索引视图的概念。 SQL Server中的视图包含了对单张表或者多张表的列的查询。 每个视图对象都有名称，可以像使用表名那样使用视图名称，例如：

CREATE VIEW WestCoastAuthors
AS 
SELECT * FROM authors
WHERE state IN ('CA', 'WA', 'OR')

现在您就可以使用视图了，就像在查询中使用表一样：

SELECT au_id, au_lname FROM WestCoastAuthors
WHERE au_lname LIKE 'S%'

大多数程序员都很熟悉视图，但可能并不熟悉索引视图。在一个非索引视图中，视图中的数据并不作为独立副本而存储在数据库中；每次使用视图时，视图中包含的查询将被执行。因此在上面的例子中，将执行获取WestCoastAuthors结果集的查询，然后再通过条件判定找出那些我们想要的WestCoastAuthors。索引视图则存储了数据副本，因此如果我们将WestCoastAuthors创建成一个索引视图，我们就拥有两份authors数据。您现在可以通过两种方式更新数据，或者通过索引视图，或者通过原始表。SQL Server因此需要对两份物理数据存储的变化进行检测，从而将一处的变更应用到另一处。这种变更检测机制和数据库引擎处理查询通知时使用的机制是一样的。

由于变更检测的这种实现方式，因此并非所有视图都可以创建索引。那些有关索引视图的限制条件对于查询通知也同样生效。例如：以上面的方式书写的WestCoastAuthors 视图就不能创建索引。要想在视图上创建索引，视图定义必须使用2部分命名法则，且必须显式地列出结果集中所有的列名。因此为了创建索引我们来修改一下视图的定义：

CREATE VIEW WestCoastAuthors
WITH SCHEMABINDING
AS
SELECT au_id, au_lname, au_fname, address, city, state, zip, phone
FROM dbo.authors
WHERE state in ('CA', 'WA', 'OR')

只有遵循了索引视图规则的那些查询才可以使用通知。注意：尽管使用了相同的机制来判定是否一个查询结果集发生了改变，但查询通知不会导致SQL Server创建数据副本，而索引视图会。您可以在SQL Server 2005 Books Online中找到有关索引视图的一系列规则。如果提交了一个附带通知请求但是违背规则的查询，SQL Server会立刻发出一个原因为“无效查询”的通知。可是，通知发布到哪里呢？

SQL Server 2005使用Service Broker传递通知。Service Broker是SQL Server中内置的异步消息队列功能。查询通知将使用Service Broker的SERVICE。此处的SERVICE是指异步消息的目的地；可以强制要求消息必须遵循被称为合同的一组规则。每个Service Broker的SERVICE始终和某个队列，也就是物理的消息目的地相关联。查询通知合同是内置在SQL Server中的，名称为http://schemas.microsoft.com/SQL/Notifications/PostQueryNotification.

注意：尽管合同在SQL Server中的对象名看似一个URL，但却与该位置没有任何联系。它只是一个对象名，就像dbo.authors是个表名而已。

总而言之，查询通知消息的目的地可以是任何SERVICE，只要该SERVICE支持相应的合同。使用SQL DDL定义service的语句如下所示：

CREATE QUEUE mynotificationqueue
CREATE SERVICE myservice ON QUEUE mynotificationqueue 
([http://schemas.microsoft.com/SQL/Notifications/PostQueryNotification])
GO

现在就可以使用myservice的SERVICE作为查询通知请求的目的地了。SQL Server通过将消息发送到SERVICE的方式发布通知。可以使用您自己的SERVICE或者让SQL Server选择MSDB数据库中的一个内置SERVICE。如果使用您自己的SERVICE，您必需自己编写代码读取和处理消息。但如果使用MSDB中内置的SERVICE，则使用预先写好的消息投递的代码。后面我还会再探讨这一点。

由于查询通知需要使用Service Broker，因此有一些其它要求：

1.必须在通知查询运行的数据库上开启Service Broker。在SQL Server Beta 2中，默认AdventureWorks示例数据库没有开启该功能，可以使用“ALTER DATABASE SET ENABLE_BROKER”的DDL语句开启该功能。

2.提交查询的用户必须具有订阅查询通知的权限。权限授予是在每个数据库级别上配置的；下面的DDL语句将授予用户'bob'在当前数据库中订阅的权限：

GRANT SUBSCRIBE QUERY NOTIFICATIONS TO bob

将通知发送给最终用户或者缓存

到目前为止，我们已经提交了正确的附带通知请求的查询到SQL Server。SQL Server在行集上进行监视，如果任何用户改变了行集，一条消息就被发送到我们选择的SERVICE。现在该做些什么呢？您可以自己编写代码负责在通知产生时读取消息并执行自定义的处理逻辑；或者您也可以使用内置的分发器替您进行处理。那么，让我们来看看分发器。

除非指定了自定义的SERVICE，否则查询通知将使用MSDB数据库中内置的名为http://schemas.microsoft.com/SQL/Notifications/QueryNotificationService作为默认的SERVICE。当消息到达该SERVICE的队列时，与队列关联的sp_DispatcherProc系统存储过程自动对消息进行处理。有意思的一点是该存储过程使用了.NET编写的代码，因此必须在SQL Server 2005实例上启用“加载NET公共语言运行时（CLR）”，自动的查询通知投递才能工作。（可以在每个SQL Server实例上启用或禁用“加载.NET CLR”）

当查询通知消息到达时，sp_DispatcherProc （从现在起，我将它称为“分发器”）检查SqlDependency通知队列中的查询通知订阅列表，然后将消息发送给每个订阅者。注意：使用分发器的时候，是由服务器将数据改变的通知告知客户端的。这样做有两个好处：客户端无须对通知进行轮询，客户端无须建立和SQL Server的连接就可以接收通知。分发器使用HTTP协议或者TCP或者私有协议将通知发送给每个订阅者。可以选择是否对服务器-客户端通信进行身份验证。通知投递到订阅者后，就从活动的订阅列表中删除该订阅。记住：每个客户端的订阅只能接收一条通知；这取决于客户端是否重新提交查询以及重新订阅。