对话会话

  • 项目

适用于：SQL ServerAzure SQL 托管实例

Service Broker 发送的所有消息都是会话的一部分。 对话是两个服务之间的会话。 对话是两个服务之间可靠而持久的双向消息流。

对话提供一次顺序 (EOIO) 消息传递功能。 对话使用会话标识符和包含在每条消息中的序列号来标识相关的消息，并以正确的顺序传递这些消息。 对话是两个服务之间可靠的、持久性消息流。

对话会话有两个参与者。 “发起方”发起会话。 “目标”接受发起方发起的会话。 参与者是否发起会话决定该参与者可发送的消息，如会话约定中所指定的。 下面的关系图显示对话的消息流：

发起方和目标之间的消息流

应用程序作为对话的一部分来交换消息。 当 SQL Server 接收到对话的消息时，会将该消息放入对话的队列中。 应用程序接收来自队列的消息，并在必要时处理该消息。 作为处理的一部分，应用程序可能会将消息发送到对话中的其他参与者。

可靠的传递

对话包含了自动消息接收确认，以确保可靠的传递。 Service Broker 将每个待发消息都保存在传输队列中，直到远程服务确认该消息。 有了这些自动确认消息，应用程序就不必再显式确认每条消息，从而可节省时间和资源。 在可能的情况下，确认消息可包含在对话的返回消息中。

注意

Service Broker 在内部处理确认消息。 这些消息不会显示在队列中，也不会传递到应用程序。如果远程服务无法访问，Service Broker 不会将其视为一个错误。 当远程服务无法访问时，Service Broker 会为该服务保存消息，直到该服务可访问或对话生存期过期为止。

对话生存期

消息在对话生存期期间可以在应用程序间进行交换。 对话生存期从本地 SQL Server 实例创建该对话时起，一直持续到应用程序显式结束该对话或收到与该对话关联的错误消息时为止。 每个参与者均有责任在应用程序收到指示错误的消息或结束会话的消息时显式结束会话。 在大多数服务中，其中一个参与者负责通过无错误地结束会话，指示会话完成且成功。 此操作是由目标执行还是由发起方执行取决于会话的目的。

起始应用程序发起对话时，它的本地 Service Broker 会为该对话创建一个会话端点。 目标应用程序的本地 Service Broker 会在其实例收到该对话中的第一条消息时，为该对话创建一个会话端点。

对话还可以保证会话生存期不超出指定的时限。 起始应用程序可以选择指定对话的最长生存期。 本地 Service Broker 和远程 Service Broker 都会跟踪此生存期。 如果对话在到达最大生存期时仍处于活动状态，会话的每一端都会将一条超时错误消息放在服务队列中，并拒绝新的对话消息。 会话的生存时间从不会超出在对话开始时所建立的最大生存期。 请注意，虽然会话结束之后应用程序仍可接收该会话的消息，但不会有该会话的新消息到达，应用程序也无法再发送有关该会话的消息。

应用程序负责通过显式地结束对话，来指示它们结束对话的时间。 Service Broker 永远不会自动结束对话。 对话将保留在数据库中，直到应用程序显式结束会话为止。 因此，即使在对话超时或 Broker 报告错误时，会话中的各参与者也必须显式发出 END CONVERSATION 语句。

会话计时器

利用“会话计时器”，应用程序可以在特定时间接收消息。 会话计时器到期时，SQL Server 会在启动会话计时器的端点处将一条会话消息插入到会话队列中。 应用程序可以将会话计时器用于任何目的。 会话计时器的一个常见用途是响应远程服务响应的延迟时间。 另一个常见用途是创建以设定间隔向远程服务发送消息的服务。 例如，服务可以使用会话计时器，每隔几分钟报告一次 SQL Server 的当前状态。 应用程序还可以使用会话计时器在特定时间激活存储过程。 这使 Service Broker 可以支持预定活动。

会话中的每个参与者在每个会话中都可设置一个会话计时器。 会话计时器不与其他参与者共享，而且会话计时器不影响会话的生存期。 当计时器过期时，本地 Service Broker 会将一条超时消息添加到本地服务队列中。 超时消息的类型名称为 https://schemas.microsoft.com/SQL/ServiceBroker/DialogTimer

另请参阅