Sun Java System Message Queue 3.7 UR1 技术概述

可靠消息传送

消息传送在两个跃点上进行:第一个跃点从代理上的物理目的地的生成方获得消息;第二个跃点从使用方的目的地获得消息。因此,在下面的三个阶段,消息可能丢失:在至代理的跃点上,当代理发生故障时在代理内存中,以及在代理至使用方的跃点上。可靠传送可保证传送过程在上述任一阶段都不会失败。由于当代理发生故障时非持久性消息总是会丢失,因此可靠传送仅适用于持久性消息。

使用了两种机制来确保可靠传送:

以下各节将介绍这两个方面的可靠性保证措施。

确认

确认是指客户端与消息服务之间为确保可靠消息传送而发送的消息。对于生成方和使用方,确认的用途是不同的。

如果是生成消息,则代理将确认收到消息、将消息传送到其目的地并将其持久存储。生成方的 send() 方法会被阻止,直至它收到此确认为止。这些确认对于持久性消息要发送到的客户端是透明的。

使用消息时,客户端确认已收到从某个目的地传送来的消息并已使用它,然后代理从该目的地中删除该消息。JMS 指定不同的确认模式代表不同的可靠度。

对于更关心性能而不是可靠性的客户端, Message Queue 服务通过提供 NO_ACKNOWLEDGE 模式来扩展 JMS API。在该模式下,代理不跟踪客户端确认,所以不保证使用方客户端已成功处理了消息。对于发送至非长期订户的非持久性消息,选择该模式可提高性能。

事务

事务是将一条或多条消息的生成和/或使用组合到一个工作单位的方法。上述客户端和代理确认过程同样适用于事务。在这种情况下,客户端运行时环境和代理确认默认在事务级别进行。当事务提交时,将自动发送代理确认。

可以将会话配置为事务,并且 JMS API 提供了启动、提交和回滚事务的方法。

在事务中生成或使用消息时,消息服务跟踪各个发送和接收过程,并只有在 JMS 客户端发出提交事务的调用时才完成这些操作。如果事务中特定的发送或接收操作失败,将引发异常。客户端代码可以通过忽略异常、重试操作或回滚整个事务来处理异常。事务提交时,所有操作都已完成。事务回滚时,所有成功的操作都取消。

事务的作用范围始终为一个会话。也就是说,可以将在单个会话上下文中执行的一个或多个生成方或使用方操作组成一个事务。由于事务只能跨越单个会话,因此不存在既包括消息生成又包括消息使用的端对端事务。

JMS 规范还支持分布式事务。也就是说,消息的生成和使用可以是大型分布式事务的一部分,该事务中包括涉及其他资源管理器(如数据库系统)的操作。必须有事务管理器(例如,Java Systems Application Server 提供的事务管理器)才能支持分布式事务。

在分布式事务中,分布式事务管理器使用在 Java 事务 API (Java Transaction API, JTA) XA 资源 API 规范中定义的两阶段提交协议,来跟踪和管理由多个资源管理器(如消息服务和数据库管理器)执行的操作。在 Java 领域中,资源管理器和分布式事务管理器之间的交互在 JTA 规范中进行了说明。

支持分布式事务是指消息传送客户端可通过 JTA 定义的 XAResource 接口参与分布式事务。此接口定义了实现两阶段提交的许多方法。当客户端进行 API 调用时,JMS 消息服务只与分布式事务管理器(由 Java 事务服务 (Java Transaction Service, JTS) 提供)协作来跟踪分布式事务中的各种发送和接收操作、跟踪事务状态并完成消息传送操作。与本地事务一样,客户端可以通过忽略异常、重试操作或回滚整个分布式事务来处理异常。


注 –

仅当 Message Queue 用作 Java Enterprise Edition 平台中的 JMS 提供者时,Message Queue 才支持分布式事务。有关如何使用分布式事务的其他信息,请参考应用服务器提供者提供的文档。


持久性存储库

另一方面的可靠性就是确保在将持久性消息传送至使用方之前,代理不会将它们丢失。这意味着,当消息到达物理目的地时,代理必须将其放入持久性数据存储库中。如果代理由于某种原因发生故障,它可以在以后恢复此消息并将此消息传送至相应的使用方。

代理还必须持久存储长期订阅。否则,当代理发生故障时,就无法向长期订户传送消息;当有消息到达主题目的地后,长期订户就会变为活动状态。

要保证成功传送消息,消息传送应用程序必须将消息指定为持久性消息,并将它们传送给具有长期订阅的主题目的地或传送给队列目的地。

第 3 章,Message Queue 服务介绍了 Message Queue 服务提供的默认消息存储库,以及管理员如何设置和配置备用存储库。