管理持久性的方法、装置和计算机程序的制作方法

专利名称：管理持久性的方法、装置和计算机程序的制作方法
技术领域：
本发明涉及持久性管理，用于数据处理系统，比如消息系统、文 件系统和数据库。
背景技术：
某些公知的消息系统提供'持久的，消息，其中消息状态信息和消 息保存到持久存储器(即非易失性存储器比如磁盘存储器)中的日志 和消息队列数据文件。持久存储的消息能够在消息系统的大多数故障 和重启动中幸存。响应磁盘故障以外的故障，消息状态信息和消息能 够从日志数据和持久存储的队列恢复。持久消息和状态信息的可恢复 性是实现有保证的仅仅一次消息传递的重要因素。
例如，消息管理器可以先将持久消息保存到磁盘存储器，再对应 用程序确认对该消息已经成功地进行了操作。在典型的消息网络中，
消息发送应用程序经由API调用发布'put—message，指令，以便将待发 的消息放置在队列中。本地消息管理器程序管理着这个队列并与其他 的本地应用程序通信，或者与分布式消息网络之内的其他消息管理器 通信，将消息传递到目标接受者。在持久消息系统中，本地消息管理 器先将消息保存到持久存储器，再对发送器应用程序确认成功地完成 了 'put—message，操作。对每个执行的'put—message，和'get一message，都 可以向磁盘写入持久消息或有关消息的数据，以便将该消息传递到其 目的地(在某些实施方案中，当消息在当前同步点管理器控制的'工作 单元，之外)，或者在提交当前工作单元时可以仅仅将该消息记入日志。 利用分布式工作单元，有可能避免在消息传递期间在许多中间点写日 志，而是将在预定义的点向持久存储器写入标识为'持久的，消息。
相反，'非持久的，消息不保存到磁盘，所以当消息管理器经历故
7障并不得不重启动时以及当消息管理器被操作员的命令终止时，这些 消息被抛弃。虽然在可恢复性和确保消息传递方面持久的消息提供了
很大优势，但是持久的消息也有性能成本。对每项'put一message，和 'get一message，操作都向磁盘写入将降低消息吞吐量并增加应用程序的 响应时间，所以非持久地应对某些消息存在着商业上的合理性。
因为确保消息传递与性能之间的折衷，IBM/^司的WebSphere MQ产品族包括支持将持久性和非持久性设置为可选的消息属性，并 且为了改进持久消息的性能已经做了相当多的工作(WebSphere和 IBM是国际商用机器公司的商标)。利用高性能磁盘存储器、优化在 无故障时性能的提交处理技术以及应付故障的高效恢复技术，已经提 高了性能。例如，1994年3月23日提交并转让给IBM公司的5,452,430 号美国专利介绍了处理持久的和非持久的消息的方案，旨在减少系统 故障恢复期间的延时，方式为在单一消息队列内分开的页面组中存储 持久的和非持久的数据。在C.Mohan and D.Dievendorff, "Recent Work on Distributed Commit Protocols, and Recoverable Messaging and Queuing"IEEE Data Engineering Bulletin, 17(1)， pages 22-28， 1994中介绍了在分布式提交协议、可恢复消息接发和排队领域中的发 展。
不过，典型的消息系统仍具有相对不可变更的持久性规范。 一种 建议是给消息系统用户 一种机会，为不同定义的系统状态指定不同的 持久性策略。在这样的消息系统中，用户将受益于对持久性控制的粒 度增大，但是在指定了持久性策略时持久行为仍然固定。
当已经将消息持久性指定为所期望的特性时，典型的消息系统仍 然在确保消息完整性上投入了太多资源。在许多应用中，高比例的个 人消息证明这种投入的商业价值太低，但是典型的现有技术解决方案 无法区分不同价值的消息，也无法考虑以持久对待的成本与不以持久 对待的风险。
除消息系统之外，在性能和持久性之间进行折衷也适用于数据 库、文件系统和其他持久系统。在数据库系统中，典型情况下数据持
8久地保存，但是也已知存储某些表时不强制写入持久存储器，所以在 低开销的存储器解决方案中能够获得查询/结构化能力的好处。这种朝 向'轻量级，数据库解决方案的趋势很可能会导致对持久性管理的灵活 方式的更大需求。文件系统日益增加地用于可靠的数据——例如在文件
系统内的XML文件中为应用程序服务器保持配置数据。对事务处理 文件系统的需求量正在增长，但是当前的解决方案未提供灵活的持久 性控制。

发明内容
本发明的第一个方面提供了根据与保存到持久存储器的成本或 者与不保存到持久存储器相关联的风险相关联的至少一条准则的评 估，管理数据处理系统中数据的持久性的方法。所述评估可以在将要 执行磁盘写入时进行，但是所述评估也可以在数据更新处理期间的多 种时机和数据处理网络内的多个点上进行。
本发明能够在消息系统、数据库系统、文件系统以及将数据保存 到持久存储器的其他数据处理系统中实施。本发明的第一个实施例提 供了根据对消息系统内的至少一条准则的动态评估，管理消息持久性 的方法。就所述消息已经由发起实体创建并发送之后进行评估的意义 来说，所述评估动态地进行。所述方法包括按照保存到持久存储器的 资源成本或性能成本以及/或者好处，判断与所述消息有关的消息数据 和/或日志记录是否需要保存到持久存储器。
在这种语境中，为具体消息做出持久性判断时所考虑的保存到持 久存储器("持久")的所述好处，优选情况下考虑所述具体消息的价 值以及丟失或复制与消息有关的数据的风险。优选情况下，持久的好 处考虑丟失消息和/或重复消息传递，即重复另一个处理操作的潜在成 本。例如，丟失消息的'成本，可以基于所述个別消息的重要性，也可 以基于所述消息系统满足所定义的服务质量要求的能力。优选情况下， 持久的'成本，考虑写入持久存储器时对性能的影响，优选情况下参考 当前可用的资源和资源约束，如对内部持久性队列的竟争。在消息经由本地消息接发管理器或经由消息系统的网络跨越网 络从发送应用程序传递到目标接收应用程序时，是否保存到持久存储 器的判断可以在多个点上进行。例如，众所周知发送器应用程序可以
发布'put一message，命令，将消息放置在由本地消息接发管理器所管理 的队列上，而所述本地消息接发管理器(即'队列管理器，)可以将所 述消息传递到所述网络内的下一个消息接发管理器，依此类推，直到 所述消息到达了所述目标应用程序的本地消息接发管理器。所述目标 应用程序然后从所述本地消息接发管理器所保持的消息队列中检索所 述消息。根据本发明，在这条通信通道内的每个消息接发管理器都可 以进行持久性判断，并且所述消息可以在一个消息接发管理器处被持 久化，但是在另一个却不被持久化，取决于影响每个所述消息接发管 理器的动态特性。
在典型消息系统中，在创建或首次发送所述消息时定义所述持久 行为，与这些系统的显著区别在于对是否写入持久存储器的这种延迟 的和潜在地重复的判断。
例如，假若消息被很快地从第 一 队列管理器QM1移动到第二队 列管理器QM2，便可以不必在QM1处持久保存所述消息。如果然后 因为所述最后的消费应用程序緩慢或非活动，所述消息在QM2处等 待了一段时间，所述消息可以在QM2处持久化。'移动器，(也称为消 息通道代理)是消息队列管理器组件，负责将消息从QM1上的传送 队列移动到QM2上的队列。如果将消息放到由QM1所管理的队列时 移动器緩慢或非活动，所述消息可以在QM1处持久化。当所述移动 器最终移动了所述消息时，如果所述消费应用程序此时活动，可以不 必在QM2处持久化所述消息。注意，这些仅仅是是否及何时期望持 久存储消息或者持久地对消息执行日志操作的灵活、动态判断的可能 效果的若干实例。在以下'实施例的介绍，部分中将介绍若干另外的实 例。
本发明的一个实施例提供了在经由消息系统处理消息期间管理 所述消息持久性的方法，所述方法包括评估一组准则的至少一条准则，所述准则组表示保存的成本和与不将数据保存到持久存储器到持 久存储器相关联的风险，以便判断有关所述消息的数据是否需要保存
到持久存储器；以及响应确定为需要保存到持久存储器的所述评估步 骤，将有关所述消息的数据保存到持久存储器。
第二实施例提供了在数据库内管理数据的持久性的方法，包括以 下步骤评估表示将数据保存到持久存储器的成本或好处的至少一条 准则，以便判断所述数据是否需要保存到持久存储器；以及响应确定 为需要保存到持久存储器的所述评估步骤，将所述数据保存到持久存 储器。对具体数据的插入、删除或更新或者对影响所述数据库的一组 操作可以执行所述评估。
本发明的另一个方面提供了包括实施以上所介绍方法的持久性 管理器的数据处理系统，例如数据库或消息系统。根据本发明一个实 施例的数据处理系统包括易失性数据存储器；非易失性数据存储器； 数据库管理器，对所述易失性数据存储器中保持的数据库表应用数据 更新；以及持久性管理器，判断数据更新是否需要保存到所述非易失 性数据存储器。所述持久性管理器评估表示保存到所述非易失性数据 存储器的成本或好处的至少一条准则，以便判断所述数据更新是否需 要保存到所述非易失性数据存储器，然后通过启动将所述数据更新保 存到所述非易失性数据存储器而响应肯定判断。
根据一个实施例的消息系统包括易失性数据存储器比如随机存 取存储器；非易失性数据存储器比如磁盘存储器；处理消息传递的消 息接发管理器；以及持久性管理器，判断有关消息的数据是否需要保 存到所述非易失性数据存储器。所述持久性管理器评估表示保存到所 述非易失性数据存储器的成本或好处的至少 一条准则，以便判断有关 消息的数据是否需要保存到所述非易失性数据存储器。所述持久性管 理器或者在对所述消息执行操作时或者在随后，能够参考当前资源成 本和/或保存到持久存储器的好处动态地执行这种判断。所述持久性管 理器响应确定为需要保存到持久存储器的评估步骤，启动将有关消息 的数据保存到所述非易失性数据存储器。
ii在本发明的一个实施例中，当日志写入即将来临时做出是否保存 到持久存储器的判断，检查在所述日志写入中应当包括哪些操作。在 另一个实施例中，所述判断由异步报警触发，比如响应正在处理这个 队列的所述应用程序或消息通道代理的关闭，或者响应队列深度超过 消息的阈值数量，或者响应消息已经排队等待的亳秒数大于阈值。
本发明的第三个方面提供了计算机程序，包括的一组指令用于控 制数据处理系统中操作的执行，以便实现以上介绍的方法。优选情况 下，所述计算机程序作为计算机程序产品提供，其中由记录介质或数 据传递介质上所记录的计算机程序代码实现所述指令组。这样的计算 机程序代码可以经由数据通信媒介的传输而获得。


以下参考附图，举例更详细地介绍本发明的若干实施例，其中
图l是业内公知的简单分布式消息系统的示意表达；
图2是可以实施本发明的消息系统的示意表达，显示了能够协同
工作以实现根据本发明实施例的持久性管理的若干系统部件；
图3显示了根据图2实施例的消息系统某些组件的更多细节； 图4A和图4B是简化的流程图，表现了根据本发明的实施例管
理持久性的方法步骤；
图5是简化的流程图，显示了根据本发明另一个实施例的方法步
骤；
图6是根据本发明另一个实施例的数据库管理系统的示意表达。
具体实施例方式
本发明可在单一数据处理系统内或分布式数据处理网络内实施， 而且与某些现有的数据处理系统相比，通过实施管理持久性的新颖方 案，提供了增强的灵活性。以下介绍的是在消息网络中使用的本发明 的第一个实施例。
典型的分布式消息网络包括经由通信链接20连接的多个数据处
12理系统IO、 15。图1中显示了仅仅包括两个相连的数据处理系统的简 单实例网络，但是消息网络可以包括例如几百个分开的数据处理系统。 消息网络中的每个数据处理系统10、 15都包括消息接发管理器30、 35，它们可以在计算机程序代码中实现或者使用电子电路在硬件中实 现。具体数据处理系统IO上的若干消息接发功能可以与执行商务处理 的应用程序40、 41整合，但是在本实施例中，应用程序40、 41、 45 和消息接发管理器30、 35是分开的、互操作的计算机程序。应用程序 40、 41、 45能够经由消息网络彼此进行通信，并且每个都能够经由消 息接发接口 (API) 50、 55与本地消息接发管理器程序30、 35通信。 每个消息接发管理器30、 35都依靠硬件处理器(未显示)的处理功能 并依靠它在其上运行的数据处理系统上的操作系统(未显示)所提供 的若千服务，而且这些消息接发管理器应付针对网络内若干系统之间 操作系统差异所需要的任何数据变换。以上介绍的数据处理系统内的 组件以及随机存取存储器70、 75和非易失性磁盘存储器90、 95都经 由业内众公知的通信总线连接。
由于本发明可适用于许多常规的数据处理系统硬件和操作系统 架构，所以本文不再更详细地介绍公知数据处理系统的标准特点。
图1的消息系统的架构相对便利了简单应用程序的开发，并且针 对与典型异构分布式数据处理环境内不同组件集之间的整合及互操作 相关联的许多问题。公用的消息接发功能可以在消息接发管理器30、 35内实现，而应用程序40、 41、 45可以写为经由消息接发API 50、 55，调用各自本地消息接发管理器的功能。诸如来自IBM公司的 WebSphere MQ消息接发管理器程序的消息接发管理器30、 35经由 消息接发管理器所管理的消息队列而提供了异步消息通信。
例如，在第一数据处理系统10上运行的第一应用程序40可以与 远程应用程序45通信，方式为将消息放置在本地消息接发管理器30 所管理的传输队列IOO上。消息队列，比如传输队列100或本地应用 程序45的输入队列110不过是由对应的消息接发管理器所保留的存储 器区域，以便在从一个程序到另一个程序的途中保持消息。虽然在图
13200780025276.3
1中示意地表示为消息接发管理器的单元，但是消息队列100、 105、 110被保持在易失性随机存取存储器70、 75中，并且在持久性管理器 80、 85的控制下被加固到磁盘存储器90、 95,正如以下介绍。
在第一系统10与远程系统15之间的通信链接20之上，在一对 消息通道代理60、 65 (即"移动器")之间建立通信通道25。本地消息 接发管理器检验传输队列100中存放的消息头，以便确定网络内的应 当向其发送消息的下一个消息接发管理器，然后移动器60、 65负责将 有关的消息从传输队列100传递到由第二个消息接发管理器35所管理 的队列。如果第二个消息接发管理器仅仅是到目的地消息接发管理器 路程上的中间节点，新的队列再次是传输队列105，在消息能够向下 一个网络节点转发之前用作该消息的临时储存库，但是如果第二个消 息接发管理器35是目的地应用程序45的本地消息接发管理器，该消 息将被放置在应用程序输入队列110中，当应用程序准备好处理该消 息时由应用程序45维护。
将消息放置在第一传输队列100上、将该消息移动到应用程序输 入队列IIO以及应用程序45从这个队列110中检索消息的步骤是异步 执行的，以至于在应用程序40、 45之间不必存在持久的专门连接。尽 管在图1中未显示，但是从第一发送系统IO到远程目的地系统15可 以存在着跨越网络的多个异步转移。
在某些公知的消息系统中，可以持久性地也可以非持久性地传送 消息，由系统管理员或发送应用程序指定。持久性管理器80、 85按照 由通信应用程序或消息接发管理器要求(或者对在这些应用程序或消 息接发管理器之间发送的全部消息要求，或者仅仅对某些具体的消息 要求)的指定持久性向持久存储器90、 95(例如非易失性磁盘存储器) 写入消息。当发送器应用程序的本地消息接发管理器30将持久消息放 置在第一传输队列100上时，该消息可以保存到本地持久存储器90(也 就是队列的副本可以保存到磁盘存储器)，并且在将消息放置到传输 队列100时以及该消息成功地从传输队列IOO移动到应用程序输入队 列110时，本地日志记录都可以写入本地持久存储器90。当消息被放
14置在应用程序输入队列110时可以将该消息和相关联的日志记录写入 到第二系统15上的第二持久存储器95,并且当目标应用程序45从这 个队列110中检索该消息时，也可以写入日志记录。
在某些消息系统中，必须先写入日志记录然后比如将消息放置到 队列上或从队列中检索该消息的操作才能定义为完成，因为为了能够 从系统故障中恢复需要这些日志记录。不过，对队列的持久副本的更 新可以'慢吞吞地，写入(作为后台任务，正常系统关闭时对慢吞吞写 入的强制除外)。
尽管在持久地写日志记录时可实现的优点是消息传递的可恢复 性和随之而来的有保证，但是这样的磁盘写入是显著的性能瓶颈。某 些公知系统提供了对分布式事务处理的支持，减少了日志记录加固到 磁盘的次数(即在分布式工作单元提交时而不是在每一次存放、得到 或其他更新操作时向持久存储器写入)。在某些公知系统中许多操作 并行运行，在单一緩冲区中组合了几种操作的日志记录，并且同时将 其强行写入磁盘。这些特点提供了性能改进，但是持久性和日志处理 仍然是性能瓶颈。
在一种建议的系统中，用户能够指定所期望的持久性策略，它能 够为不同的系统状态设置不同的持久行为。不过，当指定持久性需求 时仍然预定义了行为，所以在动态响应当前情况以及向持久存储器进 行保存的成本和好处的意义上，还未实现真正的灵活性。
本发明通过避免对所需持久性进行预定义的和不可变的指定的 限制，提供了更大的灵活性。某些持久的保存操作可以完全避免，方 式为基于包括消息价值以及保存到持久存储器的成本和好处的一组准 则进行是否保存到持久存储器的延期判断。当消息从消息发送器向消 息目的地前进时，在消息网络内的多个点上可以评估成本和好处准则。
以下参考图2介绍根据本发明第一个实施例的消息系统10。应用 程序40、 41能够彼此互动以及经由消息接发管理器30与其他应用程 序(可以位于网络中别处)互动。消息接发管理器30响应由应用程序 进行的API调用，跨越网络处理消息传递，并且利用了本地数据处理系统10的可用的网络通信特点和操作系统特点。图2示意地表示了消 息接发的本地应用程序、API 50和消息接发管理器30。在这幅图2 中还示意地表示了易失性随机存取存储器70和非易失性磁盘存储器 90。
当应用程序创建消息时，持久性属性便与该消息相关联。正如业 内公知，属性可以指定'持久的，或'非持久的，或者第三种选项，其中指 定持久性将基于消息所放置的队列的队列定义。持久性属性可以为每 条消息自动地并始终如一地设置(对于应用程序或存放消息的队列使 用默认的消息描述符设置)，应用程序也可以可选择地使用消息描述 符内的持久性字段指定各条消息是'持久的，还是'非持久的，。在典型的 消息系统中，'持久的，消息需要保存到持久存储器，而'非持久的，消息 因为应用程序能够容忍其丢失(即偶然的消息丟失)所以不需要保存 到持久存储器。因此，应用程序指定的持久性属性定义了典型的消息 系统中的后来行为。检索和读取该消息的程序可以访问该持久性属性 并且可以确保被发送的任何应答消息都具有与其正在应答的消息相同 的持久性。
在某些公知的消息系统中，消息包括两个不同的部分一应用程 序特定数据，往往称为消息内容或消息有效负载，以及消息头，包括 消息描述符(MQMD)和其他结构化的字段。应用程序的数据不限于 任何具体的数据类型而可以包括例如字符串、字节串、二进制整数、 浮点数等。结构化的字段保持着对消息的描述，包括的信息诸如创建 该消息的消息接发管理器30的版本号、按时间序列次序处理消息的时 钟值、数据长度和可能的到期时限。消息描述符由发送器应用程序40 向消息接发管理器30传递，然后由消息接发管理器30向接收应用程 序45传递。消息描述符可以包含持久性属性(MQMD持久性)和优 先级属性(MQMD优先级)，如果发送器应用程序40需要的话。提 供优先级属性是为了允许发送器应用程序指明消息的紧迫性，并且在 判断消息队列内的消息次序时消息接发管理器可以考虑优先级数值。 不过，目的地队列可以定义为先进先出(FIFO)队列，在这种情况下
16可以忽略优先级属性。
正如以上所述，本发明对持久性管理实行了不太刻板的方式，但 是本发明的某些实施例利用了以上介绍的持久性属性。在第一个实施 例中，持久性属性指明了消息是否应当永远非持久性地对待(正如以 上介绍的对非持久消息的常规对待)，或者在保存到持久存储器的好 处证明该成本值得时是否应当持久性地对待该消息。由发送应用程序 标注为'持久，的消息在消息始发站发送了消息之后便具有对其执行的 持久性判断。这种对'名义上持久，的消息的延迟的成本/好处对比有别 于常规的解决方案，它们并不在已经发送了消息之后再基于消息系统 内动态准则的评估做出持久性判断。在本发明的这个实施例中，'名义 上持久，的消息只有被消息系统在处理消息期间所评估的一组准则(即 至少一个准则)证明是有道理时才保存到持久存储器，而不是永远持 久地保存这样的消息。
发送器应用程序40通过指定应用程序特定的消息数据和消息描 述符而将新消息放在队列上。消息描述符标识目标消息队列和目标消 息接发管理器35，并且这种信息用于标识该消息应当加入的第一消息 队列。消息接发管理器的网络应对该消息从这个第一消息队列向目标 应用程序输入队列的传递(在两个应用程序运行在同 一数据处理设备 上的有限情况下，单一消息接发管理器能够支持它们之间的通信，但 是在大多数情况下，有消息接发管理器的分布式网络来支持跨越分布 式物理网络的异步消息传输)。
当消息接发管理器或接收应用程序从各自的传输队列或应用程 序输入队列中检索消息时，消息接发管理器或接收应用程序指定了有 关该消息的某些信息将被检索，并且指定了将该消息存放其中的緩沖 区存储器空闲区域(以及緩冲区存储器该区域的长度)。进行检索的 消息接发管理器按照指定的持久性属性处理该消息。
在本发明的第一个实例实施例中，非持久和'名义上持久，的消息 放置在单一消息队列内分开的页面组120、 130中，以便简化消息的排 序并且能够在发生故障时进行高效的恢复处理。在5,452,430号美国专利中介绍了这样的解决方案一只不过在5，452，430号美国专利中，持 久性属性是确定的随后持久行为而不参考保存到持久存储器的成本和 /或好处。在本实施例中，分配给非持久消息的页面组中所保持的消息 不打算被持久地保存，但是分配给名义上持久消息的页面组中所保持 的所有消息都计划写到非易失性磁盘存储器。先对持久性成本和好处 因素进行评估，再将数据实际写到磁盘存储器。
持久性成本和好处的评估可以在多个时机进行，并且可以考虑几 个因素。首先，随着消息穿过消息接发网络，在消息接发管理器向队 列开始写入消息时，可以由消息接发管理器进行评估。这使有价值的 消息能够立即被保存到持久存储器。提示执行评估的其他'触发器事 件，能够基于消息系统内的事件一比如给定队列达到了阈值尺寸时， 或者个别消息已经排队达阈值时间段时。日志操作也可以触发评估； 例如利用系统对将在毫秒内强行对运行日志进行緩冲的感知，以确定 能够用非常低的开销同时运行日志的额外操作。在这种情况下，识别 出与持久化具体日志记录相关联的低资源成本意味着可以以早于另外 的情况下将该日志记录写入磁盘。其他'触发器事件，可以包括若干系 统事件例如消息接发管理器被警告系统即将关闭或者潜在的系统故 障时。如果磁盘存储器子系统检测出某形态的坏扇区写入就可以检测 到后一种实例。
保存到持久存储器的成本和好处评估所用的这样的'触发器事件， 和阈值对每条消息可以是动态的。例如，当消息第一次存放到队列时 由消息接发管理器所进行的评估可能确定消息有相当的价值，但是价 值不足以立即写入。然后这个初始评估将设置一个短时间段作为对该 具体消息的触发器事件。当这个阶段到期(即此'触发器事件，发生) 时，可以将该消息强制写入磁盘而不进行进一步的评估，也可以执行 第二次评估。
由于初始评估可以涉及大量的处理，比如判断'消息价值，(见以 下)或其他数据，在本发明的第一个实施例中，第一次评估收集的数 据通过网络进行流动，而且对同一消息所进行的随后评估重新使用所
18收集的数据。在一个实施例中，扩充了在消息接发管理器之间传递消 息所用的通信协议，使得算出的消息价值能够随该消息传递，在相连 的消息接发管理器处能够对持久性进行高效的评估。在其他实施例中，
扩充了消息接发API以能够指定消息价值，例如在消息头的附加字段 内(正如以下更详细的介绍)。
在每个消息接发管理器30处，数据收集器组件140保持着消息 特定数据的集合，包括消息价值和更一般的消息处理统计，在评估本 地系统上保持的消息的成本和好处时使用。在规则知识库150中保持 着一组规则，并且被应用到由持久性管理器80的评估组件160所收集 的数据。收集器组件140从分析消息接发管理器30内的处理性能和数 据结构中发现多条信息，然后用这些信息更新一组数据库表。
消息价值可以由消息接发管理器以几种方式之一确定。例如，计 算消息价值时可以基于消息类型并参考与该消息的存放队列相关联的 规则。作为替代，接收消息接发管理器确定消息的价值时也可以通过 分析消息内容(例如，通信应用程序在何处应对资金的转移以及在消 息内容内何处指定价值)，或者参考消息头内的消息价值字段。后一 个实例解决方案可适用于本发明的其中消息价值由发送器应用程序经 由消息接发API指定的实施例(见以下)，以及其中消息价值由发送 器应用程序的本地消息接发管理器仅仅计算一次的实施例。
在更高级别的架构中，比如面向服务的架构(SOA)，常见的是 由实现该架构的系统保持着队列、该队列上的消息所允许的消息类型、 这些类型消息的格式以及有关该消息和它们的处理有关的其他语义信 息之间的关联。在本发明的SOA实施方案中，语义信息包括消息价值 (或者计算这些价值的SOA实施规则内的成分)。这种信息通过更高 级别的语义成分传达到消息接发管理器，而不需要消息接发API的显 式编程。消息接发管理器不需要知道这样的消息价值是已经通过消息 接发API直接提供，还是已经经由更高级别的SOA系统确定。
在更基本的系统中，利用理解消息语义并能够提取或导出消息价 值的API跨接出口也可以达到类似的效果。同样在不需要应用程序的
19程序员编写显式API代码的情况下向消息接发系统传送了消息价值。 消息接发系统同样可以不必知道消息价值信息的来源。
队列深度也受到了监控(正如在某些公知的消息接发系统中)， 并且向数据收集器组件140提供了这种数据。另外，消息在队列中已 经停留的时间连同在队列中保持的若干数据项的总数据尺寸也受到了 监控(而且在公知的消息接发系统中这种监控涉及的开销不大，因为 该信息已经可用，尽管不是显式地监控)。另外，能够监控从队列中 读出消息的速率以及消息停留在队列中的典型时间，连同更先进的基 于统计的估计结果比如到达队列头部的预期时间。CPU开销是在公知 系统中往往受到监控的另一种系统特征，由于非常高的CPU负载往往 与系统故障有关所以这种数据对持久性评估可能是重要的，另外，已 知某些程序对其他程序具有不利的影响，并且可以将其作为判断是否 执行持久性保存操作的因素。
在第一个实例实施例中，消息接发管理器30监控其内部的消息 处理速率，并且向收集器组件140提供表示每秒从队列中读取的消息 数量的数值。收集器组件对读出消息的速率应用指数平滑算法，以产 生4呆存到数据库的数值(messageProcessingRate )。收集器组件140 还监控每条消息在其各自消息队列中的位置(positionlnQueue )。向 队列添加消息时确定这个positionlnQueue数值，并且随后能够进行 更新。
消息接发管理器的收集器组件140还对故障之间的时间产生了统 计平均(meanTimeToFailure ),它包括消息接发管理器、操作系统 或数据处理系统硬件的所有故障。其他统计(它们的某一些已经受到 现有系统管理产品的监控，比如磁盘写入错误)以及很可能与系统故 障有关的外部因素比如雷暴、供电可靠性或地震风险都可以同等地使用。
收集器组件140(从消息接发管理器30或操作系统)获得表示消 息接发系统上当前负载的数值(load)和表示消息接发系统上平均负 载的统计数值(avgLoad)，以及每秒向,兹盘写入持久性消息的平均
20次数(persistPerSec )。
可以保留一个或多个timelnProcess数值以表示从队列头检索到 了消息之后处理它所花费的时间。例如，在当前消息接发管理器30 是正在管理目标应用程序的输入队列的目标消息接发管理器的情况 下，timelnProcess就是本地应用程序发布'get—message，调用而检索这 条消息与提交该消息检索操作之间的时间。在消息接发管理器是发送 器应用程序的消息接发管理器与目标目的地应用程序的消息接发管理 器之间的中间处理节点的情况下，timelnProcess是从(消息初始放置 其中的)本地传输队列头中检索消息与向另 一个节点传送该消息而提 交消息传输操作之间的时间。
用以上介绍的数据更新数据库后，该数据然后就能够由持久性管 理器80的评估组件160应用在规则知识库150中保持的一组规则进行 处理。为了计算该消息到达该消息队列头的估计时间 (timeToHeadOfQueue )， 评估组件处理positionlnQueue和 messageProcessingRate数值
timeToHeadOfQueue=positionInQueue/messageProcessingRate 评估组件还计算该消息接发管理器将保持消息的时间估计值 (timeHeld )。
timeHeld-timeToHeadOfQueue+timelnProcess 参考将保持消息的时间和故障之间的平均时间，计算具体消息丟 失的估计风险
riskOfLoss=min(l，timeHeld/meaiiTimeToFailure) 然后对该消息丟失风险的这种估计的评估可以用于判断是否执 行向持久存储器的保存。由持久性管理器80的评估组件160进行的这 些初步评估步骤考虑具体消息丢失的风险但是还没有考虑消息的价 值。虽然本发明的某些实施例在没有考虑消息价值的情况下评估消息 丢失的风险并判断所需持久性，但是优选的解决方案评估丢失消息的 成本时却根据各条消息的价值，或者作为考虑的唯一因素，或者与消 息性能统计结果或资源成本考虑相结合。以这种方式，表示丟失消息
21成本的数值可以与表示丟失消息风险的数值以及涉及系统资源需求量
的附加准则结合。例如
riskCost=messageValue*riskOfLoss
参考load与avgLoad数值以及persistPerSec数值可以计算 persistenceCost数值，在riskCost超过persistenceCost时便做出将数 据保存到持久存储器的决策这个persistenceCost可以基于执行将数 据保存到持久存储器时所需的资源，也可以计算出持久化对系统性能 影响的估计结果，并用于影响持久性的判断。
If(riskCost>persistencCost) then persistence=tme If(riskCost^persistencCost) then persistence=false 依照具体用户对消息接发应用的服务质量需求协议，可以根据消 息接发系统是需要将性能列入优先地位还是仅仅一次就确保的消息传 递进行持久性的判断。
即使是比如以上表明的简单规则也能够以改进消息接发处理系 统性价比的方式实施。虽然以上规则表明了可操作性并且展示了本发 明的动态原理可以如何实施，但是应当认识到许多替代规则也可以用 于判断持久性。这样的规则可能比以上实例更复杂，取决于持久性管 理器可得到的信息。
图3提供了根据本发明一个实施例的持久性管理器80的收集器 组件140和评估组件160的某些更多细节。组件141是收集器，收集 由消息接发管理器自己提供的信息——包括队列深度和每条消息在队 列中的位置，以及各个消息接发管理器的内部消息处理速率。收集器 140还包括分开的外部收集器组件142，它提供涉及系统负载的数据， 例如估计的出现故障的平均时间以及涉及被检测出的磁盘写入错误的 信息。組件141和142都将它们的数据提供给收集器数据库143，它 是由评估器160的评估处理组件162所用监控数据的来源。评估器160 还包括触发组件161，它响应由内部收集器组件141和外部收集器组 件142所产生的事件，并响应与持久性写入相关联的设定时间段的到 期。规则知识库150可以包含以下二者之一或兼而有之(i)涉及消息接发管理器操作特定的若干条件的规则；以及(ii)涉及数据处理 系统内但是与消息接发管理的内部工作分开的若干条件的规则。虽然 在图2和图3中持久性管理器80表示为消息接发管理器30的内部组 件，但是它的某些或全部組件都可以实施为数据处理系统10的一个或 多个组件，它们与消息接发管理器30分开但是与其合作。
让我们考虑计算电话用费的应用，电话交换机正在发出为用户记 账而发送的呼叫记录。许多记录仅仅是几美分并且某些将没有真正的 价值，而某些记录却价值相当金额(例如50美分或1美元)，呼叫记 录的一小部分价值许多美元。记账应用程序不应当丢失高价值的呼叫 记录，所以这些可以永远持久地处理，但是低于某阈值(例如1美分 或10美分)的记录可能不具有足够的价值来证明持久处理的成本值 得。利用可靠的数据处理系统，错误和故障将相对罕见并且为了改进 处理性能的缘故能够容忍少数低价值的呼叫记录丢失。中间价值的呼 叫记录可以视为名义上持久的，但是只有在估计的消息丢失风险证明 性能成本值得的情况下才保存到持久存储器。
在不同的应用中，根据与持久化的成本和好处相关联的准则评估
高价值项(将其他项视为非持久的)，也可以仅仅应用于低价值的项 (将其他项视为持久的)。
对于1美分的电话呼叫实例，第一个messageValue-l.O。假设消 息处理速率为每秒1000条消息，平均的timelnProcess为0.2秒以及 每10天一次的平均故障速率。假设该消息添加为队列上的第四十条消 息
messageValue-l.O
messagingProcessingRate=1000
PositionInQueue=40
TimeToHeadOfQueue=positionInQueue/messageProcessingRate
=0.04
TimeInProcess=0.2TimeHeld=TimeToHeadOfQueue+ timeInProcess-0.24 meanTimeToFailure=10x24x60x60=864000 riskOfLoss-min(l， timeHeld/ meanTimeToFailure)=2.78e-7 riskCost- messageValuexriskOfLoss=2.78e-7 :i口果persistenceCost=3.17e-7(riskCost<persistenceCost)，将不持 久地卩呆存该消息。
不过，10美分的电话呼叫会持久地记录，因为
riskCost=10x2.78e-7=0.00000278>3.17e-7
riskCost>persistenceCost。
应当注意，对于典型的系统，persistenceCost将不是常数。例如 假若緩冲区中保持的全部日志记录都将执行磁盘写入，在没有其他数 据要同时写入时，与刚刚进行了磁盘写之后的persistenceCost相比， 对于新消息，与单个日志记录相关联的persistenceCost可能非常低。
在电话收费的实例中，传递消息发生故障的商业成本可能非常接 近呼叫的成本(因为某些用户喜欢精确地记录他们的电话呼叫可能更 高)。重复传递的商业成本不太容易被量化(大多数用户对重复收费 的反应远远高于收费不足！)，但是消息接发系统之外的系统特点可 以用于检测重复，在此情况下消除重复可以视为处理成本而不是商业 成本。同样，公知的消息接发解决方案已经实现的协议，仔细应对了 对读取/删除消息的记录并且仔细应对了所有返回的应答。因此本说明 书主要集中在传递消息时出现故障的风险和相关联的成本，而不是重 复，但是本发明也适用于评估重复传递的成本。
基于对riskCost的计算，消息可以放置在'持久性队列，(意在保 存到持久存储器的数据项队列)上，比如以上的介绍。在一个实施例 中，队列中每条消息的这个riskCost和位置可以定期重新计算，也可 以响应诸如用户应用程序的开始或停止之类的事件而进行重新计算。 高价值的消息可以移动到队列头并快速持久化，而低价值消息的持久 化可以相对于高价值的消息延迟，以至于最低价值的消息在持久化之 前净皮处理。
24以上实例规则和涉及电话呼叫收费的具体实例仅仅展示了可以 应用于判断是否持久地保存数据的若干考虑的种类。许多替代规则可 以按不同的复杂度等级实现，根据具体系统的持久性瓶颈是否能证明
值得考虑故障预测的知识以及诸如队列深度和CPU负载之类的统计
结果，或者诸如消息尺寸之类的参数。
虽然本领域技术人员将设想出这样的规则的许多变形，但是应当 认识到，基于对保存到持久存储器的成本和好处有关的动态准则进行 评估的任何这样的判断，都脱离了其中预定义持久行为的常规解决方 案。以上介绍的实施例将能够省略某些持久保存操作，在确定不需要 保存到持久存储器的情况下，减少与将日志和消息队列写入磁盘存储 器相关联的性能瓶颈。
现在将介绍某些实例方案，进一步展示本发明在消息系统中的适 用性和潜在的好处。例如，在活跃用户(或者以上介绍的移动器)很 快地用完消息队列时，以上介绍的持久性判断可以确定添加到队列的 消息不必持久地保存。不过，如果用户因为例如用户正在使用的另一 个资源发生故障而关机，就可以执行另一个持久性判断，得出不同的 结果。使用以上的实例公式，该消息很可能保留在队列上的时间增加
将导致riskOfLoss的增加，从而导致更高的riskCost，鼓励持久地保 存队列上的消息。这种要持久化的决策可以只适用于新到达的消息， 也可以回溯地应用于正等待的全部消息。
为了展示这个实例，让我们考虑一种消息网络，其中初始产生者 经由第一消息接发管理器QM1发送消息，然后它使用移动器向第二 消息接发管理器QM2传送消息，它将消息排队以便最后的用户检索。 如果典型的消息能够快速地从初始产生者移动到QM1然后到QM2， 但是最后的用户緩慢或非活动，该消息可能不在QM1处持久化，但 是有可能将在QM2处持久化。作为替代，如果存放消息时移动器緩 慢或非活动，该消息将有可能在QM1处持久化。如果该移动器最后 移动该消息时用户已经是活动的，该消息可能不在QM2处持久化。
如果消息具有的价值非常低，在任一消息接发管理器处都不必将
25它持久化；反之如果消息具有的价值非常高，将在两个消息接发管理 器处都将该消息持久化。与趋于持久化之前被处理的低价值消息相比， 高价值的消息可以移动到持久性队列的头部并非常快速地持久化。
正如以上介绍，本发明的某些实施例允许经由消息接发API指定 消息的价值。在以上说明包括的第一实施例中，该消息的价值(例如
在新消息头字段MQMD.messageValue中规定的)与持久性属性 (MQMD.persistence )组合使用，后者规定了以下三个选项之一 PERSISTENT 、 NON— PERSISTENT和PERSISTENT一AS一Q一DEF。 NON_ PERSISTENT消息描述为常规地处理，其他消息受到评估以判 断情况是否证明它们的'名义上持久，状态被忽视。在另 一个实施例中， 消息接发系统在与持久性属性(MQMD.persiste nee )相关联的消息的 固定消息头(MQMD)内提供了额外的字段，以表示消息的价值，同 时也启用了 PERSISTENCE—BY_VALUE的新持久性属性选项。消息 发送应用程序然后能够指定以下值之一
^PERSISTENT"
'NON一 PERSISTENT"
TERSISTENT一ASJ)-DEF，
'PERSISTENCE—BY—VALUE';
消息价值字段可以是以美分为单位的32位整数或者32位浮点 数，以默认价值比如-l表明此时该字段未设定。
在另 一个实施例中，已知的'PERSISTEN1^AS—Q—DEF，属性值 可以穿过消息接发网络远达最后用户应用程序的输入队列。该属性值 可以由原始的消息接发管理器和其他消息接发管理器通过执行本发明 的评估和对持久性的判断而响应。
在又一个实施例中，不是向现有的持久性属性添加消息的价值， 而是经由API指定的消息价值可以为所有消息提供用于判断持久性的 基础。
应当注意，以上在期望减少消息或其他数据更新持久化开销的应 用程序和系统语境下，已经通过避免向持久存储器的某些写入而介绍
26了本发明。 一种替代解决方案将消息发送者的'持久性，规约视为绝对 的要求，但是允许将有价值的消息指定为'非持久性，以便当评估准则 确定这是合适的时候从持久性消息的处理中收益。例如，具有非常高 价值的消息可以持久地处理，在检测出实际的系统故障或表明系统故 障风险的某些条件之后的 一段时间也可以持久地处理全部消息。
图4和图5提供了根据本发明实施例的方法步骤的简化表达。正 如图4A所示，本方法开始于第一个应用程序40以消息有效负载和消 息头创建200 了消息，消息头包含有关发送者的信息、目标消息接发 管理器和消息队列的标识以及一组属性。在这第一个实施例中，发送 者应用程序指定了以下持久性属性之一'PERSISTENT'、 'NON_ PERSISTENT'或'PERSISTENT_AS—Q_DEF，。 应用程序发布 'put一message，命令将该消息放置到由本地消息接发管理器30所管理 的消息队列上。本地消息接发管理器根据目标消息接发管理器的标识 (以及根据在某实施例中的持久性属性，其中持久消息和非持久消息 排队在某队列内或分开的队列内的分开的页面组中)，识别要将该消 息放置其上的适宜本地队列。如果本地队列是到远程目标队列路程上 的中间传输队列，本地消息接发管理器的移动器组件随后(以及异步 地)检索220要传递到远程消息接发管理器的消息，可能经由多个中 间消息接发管理器。不过，尽管该消息保持在由本地队列管理器30 所管理的队列上，但是本地持久性管理器80负责判断230该消息和与 该消息有关的日志数据是否应当保存到持久存储器。这种判断或者定 期执行或者响应触发器条件执行。正如早先的陈述，实例触发器条件 包括诸如将该消息放置到队列上或检测出系统问题之类的事件，或者 诸如队列深度达到消息阈值数量之类的条件。如果持久性管理器确定 需要保存到持久存储器，就立即执行240保存操作(尽管在其他实施 例中，向磁盘写入的指令本身也以优先级次序排队)。如果持久性管 理器确定当前不需要保存到持久存储器，持久性管理器可以设置150 计时器，在设定的时间段结束时，对保留在队列上的所有消息做下一 次评估和持久性判断。以上介绍了图4A中所显示方法步骤的更多细节。
图4B表示了在消息起源系统以外的数据处理系统处由消息接发 管理器和持久性管理器所执行的步骤。消息接发管理器从另一个消息 接发管理器接收300消息，并且读取310该消息的消息头和其他数据 字段，以便识别目标消息接发管理器和目标队列并识别诸如优先级和 指定的持久性之类的消息属性。随后，以与图4A中所示的相同方法 处理该消息，不是移动器就是本地应用程序检索320该消息，持久性 管理器对持久化该消息的成本和好处进行其评估330，然后启动340 对磁盘的写入或者持久化延期350到计时器到期。
图5表示了根据本发明另一个实施例，在起源消息系统处所执行 的方法步骤。发送器应用程序再次创建400消息并发布标识目标消息 接发管理器和队列的'put一message，命令。不过，发送器不是显式地指 定持久性属性，而是在消息头内指定400消息的价值。本地消息接发 管理器30读取410该消息头并且确定将该消息放置在哪个本地队列 上，从而将该消息入队。在这个实施例中，将不同价值的消息保存到 同一队列。假设目标队列不是由本地队列管理器管理，本地消息接发 管理器内的移动器便随后检索420该消息，并且将该消息发送到向目 标消息接发管理器路程上的下一个消息接发管理器。消息的价值随该 消息传送，以使得持久性判断能够在该消息访问的任何消息系统中执 行。尽管该消息在本地保持，但是本地持久性管理器80负责判断是否 将该消息保存到本地持久存储器90。持久性管理器读取其队列上消息 的头信息，并且对保存到持久存储器的成本和好处进行430评估。正 如以上介绍，这种评估在评定持久保存的好处时考虑该消息的价值， 比如对于给定的消息价值和消息丢失的风险，丢失或复制消息的商业 成本。持久性管理器然后可以启动对磁盘的写入或者设置进行下一次 评估的计时器，正如以上介绍。
图6表示的数据库系统显示了本发明另一个实施例若干组件，用 于管理数据库更新的持久存储。本系统的多种组件包括处理器500、 输入/输出组件510、易失性随机存取存储器(RAM) 520、非易失性
28磁盘存储器系统530、数据库管理器540和持久性管理器550显示为 经由系统总线560连接。持久性管理器550包括数据收集器551、触 发器组件552、规则知识库553和评估器组件554。数据库管理器540 管理着RAM 520中保持的一组数据库表570，对数据库570执行读和 写数据的更新(添加、删除和更新)。收集器组件551检测数据更新， 并且将有关更新的信息和有关数据库系统内若干条件的其他信息保存 到RAM 520内的第二数据库580。评估器组件554响应由触发器组件 552识别出的触发器条件，将从规则知识库553中获得的规则应用到 在第二数据库580中保持的数据，以评估保存到持久存储器的成本和 好处。这种评估用于执行是否将数据更新保存到非易失性数据存储器 530内数据库570的持久复制品590的判断。这样提供的数据库系统 适于低价值数据项的低开销(及潜在的高性能)存储器，因为向非易 失性存储器比如磁盘存储器写入数据仅仅在评估做出了需要持久保存 的肯定判断时才会执行。
权利要求
1. 一种数据处理设备，包括处理器；易失性数据存储器；非易失性数据存储器；以及持久性管理器，管理将数据保存到所述非易失性数据存储器，其中所述持久性管理器包括评估一组准则中的至少一条准则的装置，所述准则组表示保存的成本和与不将数据保存到所述非易失性数据存储器相关联的风险，以便判断是否需要将所述易失性数据存储器中保持的数据更新保存到所述非易失性数据存储器。
2. 根据权利要求1的数据处理设备，其中，用于评估的装置包 括用于至少评估表示将数据保存到所述非易失性数据存储器的成本的 第 一准则和表示与不将数据保存到所述非易失性数据存储器相关联的 风险的第二准则的装置；以及对比所述成本和风险以做出判断的装置。
3. 根据权利要求1或权利要求2的数据处理设备，其中，所述 持久性管理器包括评估不将所述数据更新保存到所述非易失性数据存 储器时数据丢失的风险的功能。
4. 根据权利要求3的数据处理设备，其中，所述持久性管理器 包括根据所述数据更新的价值和所述数据丢失的风险，计算数据丢失 的潜在成本的功能。
5. 根据前述权利要求中任何一项的数据处理设备，其中，所迷 持久性管理器包括评估不将数据更新保存到所述非易失性数据存储器 时复制所述数据更新的风险的功能。
6. 根据权利要求1的数据处理设备，其中，所述持久性管理器 包括评估所述数据处理设备的性能特征的装置。
7. 根据前述权利要求中任何一项的数据处理设备，其中，所迷 持久性管理器包括评估将日志记录写入到所述非易失性数据存储器之 前剩余的时间段的功能。
8. 根据前述权利要求中任何一项的数据处理设备，进一步包括 消息接发管理器，其中所述持久性管理器包括的功能用于在所述消息接发管理器处理消息期间，评估一组准则中的至少一 条准则，所述准则组表示保存的成本和与不将与所述消息有关的数据 保存到所述非易失性数据存储器相关联的风险；根据所述评估判断是否将与所述消息有关的数据保存到所述非 易失性数据存储器；以及响应肯定的判断，开始将与所述消息有关的所述数据保存到所述 非易失性数据存储器。
9. 根据权利要求8的数据处理设备，其中，响应指明所述消息 是保存到所述非易失性数据存储器的候选者的消息属性执行所述评 估。
10. 根据权利要求9的数据处理设备，包括提供消息持久性选项 的消息接发API，所述消息持久性选项包括从包括以下属性值的组中 选定的至少一个消息属性值持久的； 非持久的；参考消息队列定义所确定的持久性；以及 参考消息价值所确定的持久性。
11. 根据权利要求10的数据处理设备，其中，所述消息接发API 提供用于指定消息价值的装置并且至少提供'参考消息价值所确定的 持久性，的消息持久性选项。
12. 根据权利要求8至11中任何一项的数据处理设备，其中， 所述持久性管理器的评估功能包括评估如果与消息有关的数据不保存 到所述非易失性数据存储器时数据丢失的风险的装置，以及根据所述 消息的价值评估与所述丢失相关联的成本的装置。
13. 根据权利要求12的数据处理设备，包括为经由网络进行通 信而连接的多个数据处理系统，每个数据处理系统包括处理器、易 失性数据存储器、非易失性数据存储器、消息接发管理器和相关联的持久性管理器，用于判断是否将与消息有关的数据保存到各自的非易失性数据存储器；其中，第一数据处理系统的第一消息接发管理器包括确定由所述 第 一数据处理系统的第 一持久性管理器使用的消息价值的装置，以及 向第二数据处理系统的第二消息接发管理器发送所述确定的消息价值 的装置；以及其中，所述第二消息接发管理器包括识别所述消息价值并向所述 第二数据处理系统的第二持久性管理器提供所述识别的消息价值，以 使得所述第二持久性管理器能够判断是否将与消息有关的数据保存到 在所述第二数据处理系统的非易失性数据存储器的装置。
14. 根据权利要求8至13中任何一项的数据处理设备，其中， 所述持久性管理器的评估功能包括根据算出的丢失与所述消息有关的 数据的风险，评估将与所述消息有关的所述数据保存到所述非易失性 数据存储器的好处的装置。
15. 根据权利要求8至14中任何一项的数据处理设备，其中， 所述持久性管理器响应消息队列达到阈值队列深度，启动评估、判断 和开始到所述非易失性数据存储器的保存的功能。
16. 根据权利要求8至14中任何一项的数据处理设备，其中， 所述持久性管理器响应所述消息接发管理器执行有关所述消息的操 作，启动评估、判断和开始到所述非易失性数据存储器的保存的功能。
17. 根据权利要求16的数据处理设备，其中，所述操作包括将 所述消息放置在由所述消息接发管理器所管理的队列上。
18. 根据权利要求1至4中任何一项的数据处理设备，进一步包 括数据库管理器，对所述易失性数据存储器中保持的数据库表应用数 据更新，其中，所述持久性管理器实现用于根据至少一条准则的所述 评估，判断是否需要将数据更新、添加和删除保存到所述非易失性数 据存储器的功能。
19. 一种管理数据处理设备内的数据持久性的方法，包括以下步骤评估一组准则中的至少一条准则，所述准则组表示保存的成本和 与不将数据保存到持久存储器相关联的风险，以便判断是否将数据更新保存到持久存储器；以及响应所述数据更新应当保存到持久存储器的判断，开始将所述数 据更新保存到持夂存储器。
20. 根据权利要求19的消息系统中使用的方法，其中，所述评 估至少一条准则的步骤包括评估与消息有关的数据的丟失的风险，以 及根据所述消息的价值评估所述丢失的潜在成本。
21. 根据权利要求20的方法，其中，所述消息的价值根据所述 消息内容内的货币值确定。
22. 根据权利要求20的方法，其中，所述消息的价值根据向其 发送所述消息的消息队列的属性推断。
23. 根据权利要求20的方法，其中，所述消息的价值是经由消 息接发API所指定的消息属性。
24. 根据权利要求19至23中任何一项的消息系统中使用的方 法，其中，所述评估至少一条准则的步骤包括判断持久消息队列的当 前尺寸。
25. 根据权利要求19至24中任何一项的消息系统中使用的方 法，其中，响应与消息有关操作的性能而执行所述评估步骤，以便判 断与所执行的操作有关的数据是否需要保存到持久存储器。
26. 根据权利要求19至25中任何一项的消息系统中使用的方 法，其中，所述评估步骤包括对比消息已经在消息系统处排队的时间 段和阈值时间段。
27. 根据权利要求19的消息系统中使用的方法，其中，响应指 明所述消息是保存到持久存储器的候选者的消息属性的识别而执行所 述评估步骤。
28. 根据权利要求19至27中任何一项的方法，其中，所述评估 步骤由持久性管理器执行，该持久性管理器包括数据收集器组件；以及评估器组件，对所述数据收集器组件所收集的数据应用存储的一 组规则，以判断是否将数据更新保存到持久存储器。
29. —种计算机程序，包括以程序代码实现的一组指令，用于控 制所述计算机程序在其上执行的数据处理设备的性能，以便执行根据 4又利要求19至28中任何一项的方法。
全文摘要
所介绍的是诸如消息系统、数据库系统或文件系统之类的数据处理系统内管理持久性的方法、装置和计算机程序。管理持久性的方法包括延迟评估(230、330、430)与保存到持久存储器成本和/或好处相关联的至少一条准则，而不是完全地预定义持久性行为。所述评估可以在要执行(240、340、440)磁盘写时执行，也可以在数据更新处理期间的多个时机以及在数据处理网络内的多个点处执行。在消息接发解决方案中，管理持久性的方法包括动态地评估(230、330、430)保存到持久存储器的成本和/或好处，其中在发信实体已经创建并发送了该消息之后，在消息接发网络中的多个点处执行所述评估。所述方法包括根据保存到持久存储器成本和/或好处，判断消息数据和/或与所述消息有关的日志记录是否需要保存到持久存储器。可以参考消息的价值判断持久保存的好处(400)。
文档编号G06F9/46GK101490651SQ200780025276
公开日2009年7月22日 申请日期2007年6月26日 优先权日2006年7月1日
发明者S·J·托德 申请人:国际商业机器公司