CN1711523A - 用于管理多系统群集中资源争用的方法和装置 - Google Patents
用于管理多系统群集中资源争用的方法和装置 Download PDFInfo
- Publication number
- CN1711523A CN1711523A CNA2003801030057A CN200380103005A CN1711523A CN 1711523 A CN1711523 A CN 1711523A CN A2003801030057 A CNA2003801030057 A CN A2003801030057A CN 200380103005 A CN200380103005 A CN 200380103005A CN 1711523 A CN1711523 A CN 1711523A
- Authority
- CN
- China
- Prior art keywords
- resource
- local
- demand
- contention
- waiting
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
- G06F15/163—Interprocessor communication
- G06F15/173—Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Mathematical Physics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Multi Processors (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本发明公开了一种用于通过识别其中每一用户在等待争用链中它前面的用户所持有的资源的争用链，并将系统资源分配给该链头部的用户，就好像它们的需求至少是该链中需求最大的等候者的需求，来管理用户之间对于访问多系统群集中的资源的争用的方法和装置。最佳资源分配所需的争用数据被有效分布于整个系统群集之中，即使这些系统之间的数据流极小，且没有系统具有跨系统争用的完整概观。
Description
技术领域
本发明涉及用于管理用户之间为访问信息处理系统中的串行化资源的争用。更具体地，本发明涉及用于管理包含多个这种系统的系统群集中的这种争用的方法和装置。
背景技术
资源争用是信息处理系统中众所周知的现象。当用户(例如，一进程或其他工作单元)试图访问已由另一用户持有的资源，且第二个用户所请求的访问与第一个用户的不相容时会发生资源争用。例如，如果任何一个用户请求独占地访问所讨论的资源，则将发生资源争用。资源管理器是管理竞争的请求者之间对于其控制的资源的争用的软件部件，这种管理是通过准许一个或多个这样的用户作为持有者访问该资源并将任何剩余的用户放置在等候者池中直到该资源变得可用为止来进行的。
在具有多个资源管理器和多个工作单元的诸如IBM z/OSTM操作系统的计算机操作系统中，资源争用管理是一个复杂的问题。可能形成争用链，或换句话说，争用可能跨资源。例如，作业A等待资源R1，却持有R2，而作业B持有R1，却在等待R3，而资源R3又由作业C持有。争用可能跨系统。在上面的例子中，每一作业可能在分离的系统上。争用可能跨资源管理器。例如，R1可以是GRS入队(enqueue)，R2可以是DB2TM锁存器(latch)。分别地，z/OS的全局资源串行化(GRS)部件管理入队，而IMSTM资源锁管理器(IRLM)管理DB2资源。
跨资源争用通常是在单个资源管理器(例如，GRS)内通过跟踪每一资源的持有者和等候者的拓扑并找到任何交叉点来解决的。跨系统争用通常是通过使资源管理器明了整个群集的数据(将群集作为一个单元而不是作为各独立的系统来管理)来解决的。跨资源管理器争用通常是通过使一报告产品查询所有接口并将数据相互关联，就好象它是一个虚拟资源管理器一样，来“解决”的。因为该问题对于处于争用中的资源数量是阶O(2n)的，所以它在计算上也是复杂的。
z/OS的基本MVSTM部件具有简单的效率方案(一般称为“入队提升”)：自动(及暂时)提升任何持有据报告处于争用中的资源的工作对CPU和MPL的访问，而不注意该工作的需要程度。这相当于就好象存在资源的“重要”等候者一样来管理持有者，而不管实际拓扑如何。为了理解这种方案的操作，考虑下面的例子。假设：
1.作业A持有资源R1；
2.作业B持有资源R2并等待R1；
3.作业C等待R2。
在符号上，这可以表示为链C→B→A，其中大写字母代表上述作业，而符号→(该链中的链接)表示该符号左边的作业在等待由该符号右边的作业所持有的资源。这样，上述链的意思是作业C在等待由作业B持有的资源，而作业B又在等待由作业A持有的资源。
假定这些是GRS资源，则因为作业A和B持有处于竞争下的资源，所以传统的MVS实现将帮助它们，平等地并在有限的时间内提升每一个作业。但是，帮助B不会有益处，因为B实际上在等待A。如果B本身是多任务的，则该帮助实际上可能会危害竞争的工作，而对于资源争用未产生任何作用。
发明内容
作为上述同时提交的申请的主题的本发明的一个方面包括用于管理用户之间对于访问一信息处理系统中的资源的争用的方法和装置，其中每一用户具有所指派的需求并且能够作为其正寻求访问的资源的持有者或等候者的。根据本发明的这一方面，识别出在用户链的头部的不是等候者的用户，在该用户链中具有该链中的下一用户的每一用户持有该下一用户正等待的资源。对该用户进行管理，就好像它的需求至少是该链中需求最大的等候者的需求，这优选地是通过向该用户分配系统资源，就好像它的需求至少是该需求最大的等候者的需求来完成的。
优选地，并作为本发明的这一方面的独立发明特征，通过识别资源群集，其中该群集中的每一资源或者由正等待该群集中的另一资源的用户所持有或者由正持有该群集中的另一资源的用户所等待，及确定该群集中任何资源的需求最大的等候者的需求，来识别争用链。识别身为该群集中的一资源的持有者、但未在等待任何其他资源的用户，并再次优选地通过向该资源的此持有者分配系统资源，就好象它的需求至少是该群集中任何资源的需求最大的等候者的需求，来对该用户进行管理，就好象它的需求至少是这种需求最大的等候者的需求。
优选地，响应于接收到一资源的争用状态中的变化的通知，执行识别群集的步骤。这样，如果现在资源正由等待群集中的另一资源的用户所持有，或正由持有群集中的另一资源的用户所等待，则将该资源新分配给该群集。另一方面，如果资源不再由正等待群集中的另一资源的用户所持有，或不再由持有群集中的另一资源的用户所等待，则将该资源从该群集中移除。
因此，本发明的这一方面设想将“需求”因子结合到基本系统资源分配机制中，以便可如此运行链头部的作业(例如上面的作业C，具有为1的需求)，就好像它具有该链中其他位置上的需求更大的作业的需求因子，直到其释放该资源为止。将需求的概念结合到前面的例子中，可更好地理解它怎样表现得不同。假设：
1.作业A，具有为4的需求，持有资源R1。(在本说明书中，较小的数字表示较大的需求，因此它们可被认为“需要帮助的优先级”。)
2.作业B，具有为5的需求，持有资源R2并等待R1。
3.作业C，具有为1的需求，等待R2。
符号上，这可表示为链C(1)→B(5)→A(4)，其中大写字母代表作业，括号中的数字代表那些作业的“需求”，且符号“→”(该链中的“链接”)表示该符号左边的作业在等待由该符号右边的作业所持有的资源。这样，上面的链意指具有为1的需求的作业C在等待由具有为5的需求的作业B持有的资源，而作业B又在等待由具有为4的需求的作业A所持有的资源。
以这一方式使用“需求”因子具有几个可能不是显而易见的优点。首先，它避免了帮助如上面的B的工作，因为我们理解作业B还在等待另一资源，这样避免了一个在最好的情况下是无用的、在最坏的情况下会造成对无关竞争工作的损坏的行为。第二，它给予系统资源分配器使得它能够帮助A的知识，这种帮助比在没有此知识时更多，并且是不限期的，而不是仅仅有限时间的。虽然传统实现会忽略此链，并在某一有限时间段内将A和B都作为“重要的”来对待，但对于本发明，可以理解A事实上具有为1的需求，或者说是“最重要的”，只要C在等待。第三，它给予系统资源分配器允许它在它希望的情况下放弃帮助该链中头部的持有者的知识，例如如果网络中需求最大的工作是当前的持有者的话。
本发明的这第一方面可实现于单个系统上或实现于包括多个这种系统的系统群集中。识别资源群集的本发明的变体尤其适于在多系统实现中使用，因为它需要交换仅仅本地争用数据的子集，如下面所述的那样。
作为本申请的主题的本发明的另一方面设想这样一协议，该协议用于管理多个系统之中的资源分配，同时传递对于处于争用中的多系统资源的数量的大约阶O(n)的很少的数据。
合并了上述单系统发明方面的本发明的这另一方面设想用于管理用户之间对于访问包括多个系统的系统群集中的资源的争用的方法和装置，每一用户具有所指派的需求并能够作为其正寻求访问的资源的持有者或等候者。根据本发明的这一方面，作为本地系统运行的每一个这样的系统存储本地群集数据，此本地群集数据指示根据本地系统上的争用而将资源分为一些本地群集的分组，并对于每一本地群集指示对于该本地群集中的一个或多个资源的需求。每一系统还从作为远程系统运行的、系统群集中的其他系统接收远程群集数据，此远程群集数据对于每一这种远程系统指示根据该远程系统上的争用而将资源分为一些远程群集的分组，并对于每一远程群集指示对于该远程群集中的一个或多个资源的需求。每一本地系统组合本地群集数据和远程群集数据，以生成组合群集数据，该组合群集数据指示根据所述各系统之中的争用而将资源分为一些组合群集的分组，并对于每一个组合群集指示对于该组合群集中的一个或多个资源的需求。然后，每一本地系统使用这一组合群集数据，来管理该组合群集中的资源的本地系统上的持有者。
优选地，本地、远程和组合群集数据指示所考虑的群集中任何资源的需求最大的等候者的需求，且通过识别未在等待任何其他资源的持有者及向这种持有者分配系统资源，就好像它们的需求至少是相应组合群集中的任何资源的需求最大的等候者的需求，来管理该组合群集中的资源的本地系统上的持有者。
优选地，如果每一本地系统上的一用户在等待另一资源的时候正持有一个资源，则该本地系统将该对资源分配给一共同本地群集，并且响应于接收到关于该本地系统上的一用户的资源争用状态中的变化的通知，该本地系统更新该本地群集数据。每一本地系统还将其包括任何更新的本地群集数据传送到远程系统，该些远程系统将所传送的群集数据作为相对于接收系统的远程群集数据来对待，然后据此更新它们的组合群集数据。所传送的本地群集数据指示资源、根据该本地系统上的争用该资源被分配到的群集、及在该本地系统上对于该资源的需求。
使用来自该群集中每一参与的资源管理器实例的部分数据(而不是全部资源拓扑)，以及“需求”的度量，每一系统单独理解一资源的需求最大的等候者(包括跨“以上各项”资源的传递闭包中的任何等候者)是否比该链头部的资源的任何持有者需求更大是可能的。然后，该系统可向这种持有者分配资源，就好像它们的需求度量不低于需求最大的被阻塞的那件工作。
该协议每一资源只传送一组信息，而不是来自每一系统的持有者和等候者的完整列表，从而没有系统具有该整个群集之上的争用的完整概观。该数据本身仅包括：对群集唯一的资源名称、发送系统上的需求最大等候者的需求值、及对发送系统唯一的令牌。如果对于两个资源，后面的令牌匹配，则它们的管理必须结合起来(仅根据发送系统的本地数据来分配这些令牌)。该协议还只发送关于处于争用中的资源的数据，即使拓扑中的某些件工作持有未处于争用中的其他资源。可以各种方式对发送系统群集信息进行编码。这样，不是仅根据发送系统上的本地争用发送令牌，而是如在一优选实施例中那样，本地系统也可根据远程争用发送群集名称，以及非平凡群集分配(即对包括不只一个资源的群集的分配)是基于本地还是基于远程信息的指示。
优选地，本发明实现为计算机操作系统的一部分，或作为与这种操作系统协同工作的“中间件”软件。这一软件实现包括以指令程序为形式的逻辑，其中的指令程序可由硬件机器执行以完成本发明的方法步骤。该指令程序可包含在使用半导体、磁、光和其他存储技术、包括一个或多个卷的程序存储装置中。
附图说明
图1示出包含本发明的计算机系统群集。
图2A-2C示出各种类型的争用链。
图3示出向争用链头部的用户分配资源的过程。
图4示出在几个系统上的事务和资源之间典型的争用情形。
图5示出响应来自本地资源管理器的通知而执行的一般过程。
图6示出响应接收到来自远程系统的争用数据广播而执行的一般过程。
图7A-7G示出各种操作示例中的多系统争用状态。
图8A-8H示出在本发明的一个实施例中用于存储争用数据的各种数据结构。
图9示出图4中所示的争用情形怎样由群集各系统中的一个系统所捕获。
具体实施方式
图1示出了包含本发明的计算机系统群集100。群集100包含由任何适当类型的互连104连接到一起的各系统102(Sy1，Sy2，Sy3)。虽然示出了示例性的三个系统，但本发明不限于任何特定的系统数量。群集100具有一个或多个全局或多系统资源106，它们由来自各个系统的请求者所争用。
该群集的每一系统102可包括一分离的物理机器或一个或多个物理机器的一分离的逻辑分区。每一系统包含操作系统(OS)108，该操作系统除了执行本发明的功能之外，还执行提供系统服务和管理系统资源的使用的通常功能。虽然本发明不局限于任何特定的硬件或软件平台，但优选地，每一系统102包括运行于IBM zSeriesTM服务器或这种服务器的逻辑分区之上的IBM z/OS操作系统的实例。
每一系统102包含一个或多个请求者110，这些请求者相互之间争夺对多系统资源106及可选地本地资源112的访问，其中本地资源112只对同一系统上的请求者可用。请求者110可包括争夺对资源106或112的访问，且为了分配系统资源的目的被作为单个实体来看待的任何实体。
(分配给请求者110的系统资源应该与作为请求者之间的争用对象的资源106和112区分开。系统资源是以通常对请求者自身透明的方式分配给请求者110的，以提高诸如吞吐量或响应时间的某种性能度量。另一方面，资源106和112由请求者作为它们的执行的一部分而显式地请求。在必须区分它们时，使用诸如“串行化资源”或类似的术语来称呼后一类资源。)
每一操作系统108包含几个对本发明来说有兴趣的部件，包括一个或多个资源管理器114和工作负荷管理器(WLM)116。每一资源管理器114管理竞争的请求者110之间对于它控制的资源106和112的争用，这种管理是通过准许一个或多个这样的请求者作为持有者访问资源并将任何剩余的请求者放置在等候者池中直到该资源变得可用为止来进行的。尽管本发明并不限于任何特定的资源管理器，但一个这样的资源管理器(用于多系统资源106)可以是z/OS操作系统的全局资源串行化(GRS)部件，该部件在诸如IBM出版物z/OS MVS Planning：Global Resource Serialization(z/OS MVS规划：全局资源串行化)，SA22-7600-02(2002年3月)的参考文献中进行了描述，在此引入该参考文献作为参考。此外，虽然资源管理器114被描述为是操作系统108的一部分(如GRS是z/OS的一部分)，但其他资源管理器(诸如IRLM)可以独立于操作系统而存在。
工作负荷管理器(WLM)116根据指派给工作单元(或它所属于的服务类)、并在某种意义上反映该工作单元相对于正被处理的其他工作单元的相对优先级的“需求”值向该工作单元分配系统资源(其可能是地址空间、工作区域(enclave)等)。虽然本发明并不限于任何特定的工作负荷管理器，但这样的一种工作负荷管理器是IBM z/OS操作系统的工作负荷管理部件，该部件在诸如IBM出版物z/OS MVS Planning：WorkloadManagement(z/OS MVS规划：工作负荷管理)，SA22-7602-04(2002年10月)，和z/OS MVS Programming：Workload Management Services(z/OS MVS程序设计：工作负荷管理服务)，SA22-7619-03(2002年10月)的参考文献中进行了描述，在此将这两个参考文献引入作为参考。这样的工作负荷管理部件与IBM z/OS操作系统的系统资源管理器(SRM)部件协同进行工作，如在诸如IBM出版物z/OS MVS Initialization andTuning Guide(z/OS MVS初始化和调整向导)，SA22-7591-01(2002年3月)，尤其第3章(3-1页到3-84页)的参考文献中描述的，在此将该出版物引入作为参考。由于这些部件交互的特定方式不是本发明的一部分，假定这些部件都由图1中标记“WLM”的框116所标引。
向用户指派需求值的特定方式和根据所指派的需求值向用户分配系统资源的方式都不是本发明的一部分。本领域中公知的多种技术中的任何一种都可用于这两种方式之一。优选地，上述需求值应该是在整个该系统群集之中具有相同意义的值。在所示的实施例中，它是根据现行WLM策略计算的动态值，该值将资源组限制和重要性集成到可在各系统之间被可靠比较的单个数量中。虽然顺序是任意的，但在本说明书中，较小数字代表较高需求或优先级，从而具有为1的需求的用户比具有为5的需求的用户“需求更大”。
图2A-2C示出在系统群集100中的资源106和112之中可能形成的各种争用链。这些链更正式地被称为有向图，但这里使用链的术语。在这些链中由箭头表示的每一链接代表这样的一关系，其中某一用户(由箭头尾部的节点代表)在等待由另一用户(由箭头头部的节点代表)持有的资源。这种关系的“传递闭包”是通过包括涉及该链的任何节点的所有这种关系而形成的链，从而如果顺着这些箭头行进，则所有节点最终指向没有在等待争用中的任何资源并因此位于该链的头部的持有者。(下面在图2D的说明中讨论一个链是否能具有不只一个头部。)
图2A示出在上面背景技术和发明内容部分中描述的争用情形，其中用户C在等待由用户B持有的资源R2，用户B又在等待由用户A持有的资源R1。如这里所公开的，向作为持有者而不是等候者并因此处于该链头部的用户A分配系统资源，就好象它的需求至少是等候者B和C中需求最大者的需求一样，因为它的这两个等候者都将从使A完成对资源R1的占用中受益。用户B也是持有者，但它未被给予这一优先的分配，因为它在等待资源并因此未在运行；这样，此时向B分配更多资源的是没有意义的(尽管以后在B作为持有者获得资源R1时会有意义)。
图2A中所示的争用情形是直的链，其中每一用户正持有和/或等待由单个用户所持有的资源。但是，一般地说，争用链可以分支，从而单个用户可能正持有由多个用户所等待的资源，或在等待由多个用户所持有的资源。某些资源还可能被请求共享访问，从而允许多个同时的持有者。
图2B示出具有第一类型分支的争用情形，其与图2A中所示情形的不同之处在于，现在一附加用户D在等待由用户B所持有的资源R3。这里，向用户A分配系统资源，就好象它的需求至少是等候者B、C和D中的需求最大者的需求一样，因为所有这些等候者将从使A完成对资源R1的占用中受益。
图2C示出具有两种类型的分支的争用情形，其与图2A中所示情形的不同之处在于，现在用户C在等待由用户D控制的附加资源R3，而用户D在等待由用户A控制的资源R4。这里再次地，向用户A分配系统资源，就好象它的需求至少是等候者B、C和D中的需求最大者的需求一样，因为所有这些等候者将从使用户A完成对资源R1的占用中受益。
最后，图2D示出具有第二类型分支的争用情形，其与图2A中所示链的不同之处在于，现在用户C还在等待由用户D持有的资源R3，而用户D又在等待由用户E持有的资源R4。理论上，可将这分析为两个部分重叠的链，每一个链具有一个头部，一个链是C→B→A，而另一个链是C→D→E。在第一个链中，用户A被分配系统资源，就好象它的需求至少是等候者B和C中的需求最大者的需求一样，而在第二个链中，用户E被分配系统资源，就好象它的需求至少是等候者C和D中的需求最大者的需求一样。
参照图3，对此进行总结，在理想的实现中，将首先识别不是等候者的在用户链头部的用户(步骤302)，在该链中每一具有该链中下一用户的用户正持有该下一用户正在等待的资源。在图2D中，这对于包括用户A-C的链来说将是用户A，在包括用户C-E的链中将是用户E。然后，将向在该链头部的用户分配系统资源，就好象它的需求至少是该链中需求最大的等候者的需求(步骤304)。也就是说，如果存在这样的具有比该链头部的用户更大的需求的需求最大的等候者，则将根据这样的等候者的需求向此用户分配系统资源，如果此等候者的需求大于该用户的需求的话。
在这种作为两个链的对待中，用户A的资源分配不依赖于用户D的需求，因为用户D的分支(在箭头方向上前进)不馈入用户A，因此用户D将不会从帮助用户A中受益。基于同样原因，用户E的资源分配也不依赖于用户B的需求。因此，在优选实施例中，将这些链(或不如说是构成这些链中的链接的资源)分析为两个单独的资源群集：第一个包含资源R1-R2，第二个包含资源R3-R4。在第一个群集中，用户A被分配了系统资源，就好象它的需求至少是该第一个群集中的任何资源(R1和R2)的等候者(B和C)中需求最大者的需求一样。类似地，在第二个群集中，用户E被分配了系统资源，就好象它的需求至少是该第二个群集中的任何资源(R3和R4)的等候者(C和D)中需求最大者的需求一样。
在所有上面的例子中，争用链是无环的，意味着不能通过顺着这些链接沿着它们的箭头方向形成闭路。如果存在这样的闭路，则将会存在资源死锁，该死锁只能通过终止一个或多个与该死锁有关用户打破。
现在转到多系统实现的详情中，图4示出了几个系统上的事务和资源之中典型的争用情形。在该图中，系统Sy1上的事务TxA(具有为1的需求)在等待由系统Sy2上的事务TxB(具有为2的需求)和TxD(具有为4的需求)持有的资源Ra。系统Sy2上的事务TxB又在等待由系统Sy3上的事务TxC(具有为3的需求)如系统Sy3上的事务TxE(具有为5的需求)一样持有的资源Rb。
在该例中，考虑系统Sy2，来说明系统Sy1-Sy3如何管理争用。根据本发明的一个方面，系统Sy2不存储或维护群集中争用的完整全局图画，而是存储或维护如下表中示出的这种争用信息的子集。
| 系统Sy2 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cab | Ra | TxB(2)，TxD(4) | Sy1 | 1 | 1 | |
| Cab | Rb | TxB(2) | Sy3 | 5 | 2 | |
| Cab | 群集 | Ra、Rb链接 | 1 | |||
如上表中所示，系统Sy2存储它的正在或者作为持有者或者作为等候者争用资源的本地事务TxB和TxD的一组完整的争用数据(“本地系统信息”)。对于本地事务在争用的每一个这种资源，Sy2跟踪本地持有者和等候者，包括它们的固有“需求”值。系统Sy2也将资源Ra和Rb分配给了共同群集Cab，因为至少有一个本地事务(TxB)既是一个所请求资源(Ra)的持有者，又是另一个所请求资源(Rb)的等候者。
上表中所示的数据、或由WLM的本地实例以其他方式跟踪的数据(或者通过按其原样存储的或者通过按需要从其他数据中导出的)包括本地群集数据、远程群集数据、和组合群集数据。本地群集数据指示根据本地系统上的争用而将资源分为本地群集的分组，并对于每一个这样的本地群集，指示该本地群集中任何资源的需求最大的等候者的需求。类似地，特定远程系统的远程群集数据指示根据该远程系统上的争用而将资源分为远程群集的分组，并对于每一个这样的远程群集，指示该远程群集中任何资源的需求最大的等候者的需求。最后，通过组合相应的本地和远程数据而生成的组合群集数据指示根据这些系统之上的争用而将资源分为组合群集的分组，并对于每一这样的组合群集，指示该组合群集中任何资源的需求最大的等候者的需求。
在上面的表中，标题“本地系统信息”之下的项目代表本地群集数据，因为它们只基于在本地用户等待资源或持有处于争用下的资源的意义上的本地争用。可通过查看“本地系统信息”之下的“等候者”列，来确定资源的需求最大的本地等候者的需求。因此，对于资源Ra不存在本地等候者(并因此没有“需求最大的”本地等候者)，而对于资源Rb，需求最大的等候者(TxB)具有为2的需求。在表中未明确示出根据本地争用而将资源分为群集的分组，但可通过寻找其中一本地用户正持有一个资源而在等待另一资源的资源项目对来获得。这样，在上面的表中，用户TxB作为资源Ra的持有者和资源Rb的等候者的列出意味着资源Ra和Rb根据本地争用数据被分配给一共同群集。
类似地，在标题“远程等候者信息”之下的项目代表远程群集数据，因为它们只基于特定远程系统上的争用。对于在“系统名称”列中对于资源列出的每一远程系统，在相邻的“NQO”列中指出了需求最大的等候者的需求。在上面的表中未指示根据来自特定远程系统的争用数据而将资源分为群集的分组，但该分组由本地WLM实例进行跟踪，以便它能够与本地群集分配信息组合以获得组合群集分配。群集的组合是以直接的方式进行的。这样，如果第一个系统(根据它的本地争用数据)向一共同群集分配资源A和B，第二个系统类似地向一共同群集分配资源B和C，而第三个系统向一共同群集分配资源C和D，则所得到的组合群集包含资源A、B、C和D。
另一方面，第一列(“资源群集”)代表组合群集数据，因为资源向一群集的分配是基于本地群集数据和远程群集数据两者的。最后一列(“NQO”)同样代表组合群集数据，因为所列出的需求是所有系统上的资源的需求最大的等候者的需求(被报告给本地系统的)。
系统Sy2可以上面示出的表格形式存储争用数据，但更通常的是将这种数据分布于多种数据结构上，以优化操作的简易性，如下面进一步描述的那样。
图5示出WLM的本地实例响应来自本地资源管理器的争用通知而执行的一般过程500。虽然描述了特定的步骤顺序，但该顺序可以变化，只要在每一步骤执行时所需的输入数据可用即可。
在该WLM实例接收到来自本地资源管理器对涉及到本地用户时的资源争用状态中的变化的通知时，过程500开始。这种变化可以表示下述各项中的任何一个：
1.本地用户已变成由另一用户持有的资源的等候者。
2.本地用户不再是一资源的等待者。这可能是因为它已作为持有者获得了该资源，或因为它不再作为或持有者或等候者对该资源感兴趣(可能因为它已终止并因此不再存在，如下面的示例中所描述的那样)。
3.由本地用户持有的资源现在处于争用中。
4.由本地用户持有的资源不再处于争用中。
来自本地资源管理器的通知将标识该资源以及其本地持有者和等候者。在优选实施例中，WLM从一未单独示出的SRM部件获得这些持有者和等候者各自的“需求”(它们的固有需求，而不是它们根据本发明而改变的需求)；虽然，此数据的特定来源不构成本发明的一部分。
响应从资源管理器实例接收到这种通知，WLM的本地实例首先更新考虑中的资源的本地争用数据(步骤504)。这种更新可包括创建本地系统上新处于争用中的资源的新项目，更改本地系统上已处于争用中的资源的已有项目，或删除本地系统上不再处于争用中的资源的已有项。这种本地争用数据包括持有或等待资源的任何本地用户的标识，和这种用户的“需求”。
在更新本地争用数据之后，如果需要，则WLM的本地实例更新该资源的群集分配(步骤506)。默认地，该资源被分配给只包括它自己作为成员的平凡群集。该资源被分配给包括至少一个其他资源的非平凡群集，如果本地争用数据或远程争用数据要求这样的分配的话。该资源被根据本地争用数据分配给包含另一资源的群集，如果该本地争用数据指出同一本地用户在持有这两个资源中的一个而在等待另一个的话—也就是说，该资源或者由在等待另一资源的用户所持有，或者由持有该另一资源的用户所等待。该资源被根据远程争用数据分配给包含另一资源的群集，如果该远程争用数据指出至少一个远程系统已根据该远程系统本地的争用数据将这两个资源分配给了共同群集的话。因此，这一群集分配步骤可能包括：(1)保持该资源的群集分配不变；(2)将该资源新分配给非平凡群集，如果改变过的本地争用数据和任何已有的远程争用数据要求这样的分配的话；(3)打破已有群集，如果改变过的本地争用数据和任何已有的远程争用数据不再要求这样的分配的话。如果该资源的群集分配被改变，则同时同样地修改该改变所影响的其他资源的群集信息。
同时，WLM的本地实例更新该资源的、仅根据该资源的本地争用数据而赋予的“需求”值(步骤508)。这一赋予的需求是该资源的任何本地等候者的需求中最大的，如由该资源的本地争用数据所指示的。虽然这一步骤作为在群集分配步骤之后的步骤而示出，但这些步骤的顺序是不重要的，因为每一步骤都不使用另一步骤的结果。
在已对该资源的群集分配和赋予的需求值进行更新之后的某一时间点，WLM的本地实例更新它的组合群集数据，该组合群集数据包括：(1)根据本地和远程争用数据两者而赋予的该资源的需求值(上表中的“NQO”列)；(2)根据本地和远程争用数据而将该资源分为组合群集的分组；和(3)该资源群集作为一个整体而被赋予的“需求”值(步骤510)。最后一个所提的值仅是构成该组合群集的任何资源的需求中最大的需求，这里，该需求同样基于构成该群集的资源的远程以及本地争用数据两者。
然后，WLM的本地实例将它的更新后的本地争用数据的概要广播到该群集中的其他系统(步骤512)。该数据概要包括：
1.本地系统名称；
2.资源名称。如果该资源是多系统资源，则资源名称是在整个群集之中被认可的、该资源的实际名称。如果该资源是本地资源，则资源名称是作为实际本地资源名称的“代理”的一般本地资源名称，如下面的示例2中所描述的那样。
3.标识该资源被分配到的群集的群集ID。该值是严格本地的；接收系统比较该值，以查看是否有两个资源属于发送系统上的同一群集，但关于该值的结构和内容不进行任何假设。在下面的示例中，群集名称作为该群集中多系统资源的串接而给出，这完全是作为方便读者理解的助记手段。但是，在优选实施例中，“群集名称”实际上是接收系统只能对与起源于同一发送系统的其他群集ID的相同性进行测试的不透明“群集ID”。
4.完全基于发送系统的“本地系统信息”—即该资源的需求最大的本地等候者—的、该资源的“需求”。这可被认为是该系统认为在只考虑它的数据的情况下该需求应该是什么的表决。如果不存在该资源的本地等候者，则传送指示不存在本地需求的哑值，如下面的示例1中所描述的。
5.对发送系统上的任何事务是否强制该资源被包括在该群集中，即该资源是否根据本地争用数据被分配给非平凡群集的指示。这是布尔值，但在本说明书中给予它的值不是“是/否”，而是本地/远程。本地意味着：(1)发送系统具有至少一个既是一个资源的等候者又是另一个资源的持有者的事务；以及(2)该同一事务是该资源的等候者或持有者(因此发送系统要求与该(些)事务连接的一组资源作为一组被管理)。远程意味着发送系统的本地数据中没有什么要求该资源作为非平凡群集的一部分。平凡群集仅具有一个资源，且其始终具有“远程”的值，以使群集操作代码稍微简单一些。
如果已存在群集重新分配，则WLM还为该重新分配所影响的每一其他资源广播同样的信息。
最后，本地WLM实例对本地用户的“需求”值进行任何必要的调整(步骤514)。更具体地，WLM调整不同时是另一资源的等候者(并因此在争用链的头部)的、一个资源的任何本地持有者的“需求”，以便其至少与包含该资源的群集中需求最大的等候者的固有需求相匹配。调整后的值是实际上用于向持有者分配系统资源的赋予的“需求”值，而不是指派给该用户(并用于向其他用户赋予值)的固有需求值。这样，如果赋予特定需求值的原因不再存在，则赋予一个用户的需求值恢复为固有需求值或一个更小的赋予的需求值。
图6示出WLM的本地实例响应于接收到来自远程系统上的WLM实例的远程争用数据的广播(步骤602)所执行的一般过程600。此广播对于每一受影响的资源包括在步骤512的描述中所列出的信息。
响应于接收到这种通知，WLM的本地实例首先更新考虑中的资源的远程争用数据(步骤604)。如同在步骤504中描述的本地争用数据的更新一样，这种更新可包括在创建远程系统上最近处于争用中的资源的新项目，修改远程系统上已经处于争用中的资源的已有项目，或删除远程系统上不再处于争用中的资源的已有项目。此远程争用数据包括具有该资源的等候者的任何远程系统的标识，以及该远程系统上对该资源需求最大的这种等候者的需求。
在更新它对于该资源的远程争用数据之后，WLM的本地实例更新它对于该资源的组合群集数据，如在步骤510中所进行的那样。如在步骤510中，所更新的组合群集数据包括：(1)该资源的根据本地和远程争用数据两者而赋予的需求值；(2)根据本地和远程争用数据两者而将该资源分为组合群集的分组；以及(3)根据本地和远程争用数据两者将该资源群集作为一个整体而赋予的“需求”值(步骤606)。
最后，如在步骤514中一样，本地WLM实例通过调整不同时是另一资源的等候者的、一个资源的任何本地持有者的“需求”，来对本地用户的“需求”值进行任何必需的调整，以使其至少与包含该资源的群集中需求最大的等候者的固有需求相匹配(步骤608)。
详细示例和情形如下：
示例1(“简单”传递闭包实例)
本示例是一跨系统传递闭包实例：涉及不只一个资源，且帮助持有一个资源的需求小的用户，以使等待不同资源的另一(需求大)用户前进。该拓扑是多系统的，具有不同系统上的、相同资源的持有者和等候者。
这示出了当在同一资源群集中只涉及多系统资源时所发生的情况，因此它是“简单”传递闭包实例。
该例中的标号如下。每一持有者和等候者是一个事务(Txn，例如TxA、TxB)，并具有一个NQO(入队顺序)值。NQO值是这样的值，即更小的值是需求更大的(更值得帮助)。每一系统都被编号(Sy1、Sy2)，并且所有这些系统都在同一“系统群集”中。每一资源具有一个小写字母(Ra、Rb)，且在范围上是多系统的。每一资源群集具有一个或多个小写字母(Ca、Cab)，表示该群集中的资源列表。对获得资源的请求是请求独占控制，除非另外指出。
在时间顺序上，事件序列如下：
| 时间(t) | 事件 |
| 1 | 无争用 |
| 2 | Sy1：TxB获得Ra。 |
| 3 | Sy2：TxC获得Rb。 |
| 6 | Sy1：TxB请求Rb，并由于TxC持有它而被暂停。 |
| 7 | Sy2：TxA请求Ra，并由于TxB持有它而被暂停。 |
| 10 | Sy2：TxC释放Rb。 |
| 11 | Sy1：TxB被恢复并获得Rb。 |
| 12 | Sy1：TxB释放Rb。 |
| 13 | Sy1：TxB释放Ra。 |
| 14 | Sy2：TxA被恢复并获得Ra(无争用)。 |
在t＜6时，不存在争用，因此在每一系统上都不存在WLM争用数据。
在t＝6时，争用形成(Sy1：TxB请求Rb并由于TxC持有它而被暂停)。结果，Sv1：
1.开始跟踪对资源Rb的争用。
2.创建只包括Rb的资源群集。
3.将TxB添加到Rb的本地等候者列表中。
此时，Sy1上的状态如下：
| 系统Sy1 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cb | Rb | TxB(4) | ||||
当Sy1接着重新估算它的资源拓扑时，它为Cb计算NQO。
1.由于Sy1知道的在Rb的拓扑中涉及的需求最大的实体(事实上，此时仅有的一个)是TxB，所以它使用TxB的NQO(4)作为Rb的NQO。
2.为Cb中的所有资源计算了NQO之后，它为Cb计算作为Cb中所有资源的NQO中需求最大者的NQO。这将为4的NQO从Rb传播到Cb。
3.由于Rb是多系统资源，所以Sy1将Rb的信息广播到该系统群集中的所有其他系统。如上面所述的，为Rb发送的信息包括系统名称、资源名称、群集ID、资源的完全基于发送系统的“本地系统信息”的NQO、以及布尔值(本地/远程)，其中该布尔值被设为“本地”时表示发送系统上的一个事务强制将该资源包括在该群集中。
4.根据上面的说明，所发送的数据是：Sy1、Rb、Cb、4、远程。
此时，Sy1上的状态如下：
| 系统Sy1 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cb | Rb | TxB(4) | 4 | |||
Sy2接收这一信息；同时，Sy2上运行的资源管理器实例向Sy2通知有关Rb的争用。这些操作的顺序是无关紧要的，但会以先前描述的顺序将它们列出。代码中的仅有“技巧”在于，如果Sy2上的资源管理器赢得了这个比赛，则当远程数据到达时，该代码必须认识到它已经使一个等同的群集被构建，并将远程信息添加到它已有的数据中。
在从Sy1接收到远程信息之后，有关Sy2的状态如下：
| 系统Sy2 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cb | Rb | Sy1 | 4 | |||
一旦Sy2的本地资源管理器向Sy2通知了对于Rb的争用，则在Sy1和Sy2上的状态如下：
| 系统Sy1 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cb | Rb | TxB(4) | Sy1 | 4 | ||
| 系统Sy2 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cb | Rb | TxC(5) | Sy1 | 4 | 4 | |
应该注意，Sy2上Rb的本地NQO是4，而不是5，5是TxC的NQO。首先，资源持有者的NQO从不会影响该资源的NQO；由于该持有者正在运行，所以WLM的策略调整代码已经在隐式地使用该NQO。其次，Sy2现在知道在该系统群集中的别的地方，具有为4的NQO的事务正在等待；由于4被定义为比5需求更大，所以Rb的NQO必须不低于4的需求。
在t＝7时，对另一资源形成争用(Sy2：TxA请求Ra并由于TxB持有它而被暂停)。图7A示出了在t＝7之后的拓扑。
由于资源Ra也具有多系统范围，这导致与刚刚对于Rb发生的相同的握手(handshake)，其产生的状态如下：
| 系统Sy1 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Ca | Ra | Sy2 | 1 | 1 | ||
| Cb | Rb | TxB(4) | 4 | |||
| 系统Sy2 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Ca | Ra | TxA(1) | 1 | |||
| Cb | Rb | TxC(5) | Sy1 | 4 | 4 | |
一旦Sy1上的资源管理器实例向Sy1通知了对于Ra的争用，Sy1执行将Ca和Cb链接到(新的)群集Cab中的关键步骤。在只是被通知了对于Ra的争用之后，有效的(但到目前为止不完全的)状态可能是(根据代码实现这些或者是两个分离的步骤或者是一个结合的步骤，这里是将它们分离显示的)：
| 系统Sy1 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Ca | Ra | TxB(4) | Sy2 | 1 | 1 | |
| Cb | Rb | TxB(4) | 4 | |||
当系统Sy1接着重新估算它的拓扑时，它根据本地信息知道单个事务(TxB)涉及两个不同的资源(Ra和Rb)，且因此必须将对这些资源的管理结合起来(换句话说，Ra和Rb必须在同一资源群集Cab中)。该群集的NQO是它的组成资源的需求最大的NQO(在这个实例中是1)。
| 系统Sy1 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cab | Ra | TxB(4) | Sy2 | 1 | 1 | |
| Cab | Rb | TxB(4) | 4 | |||
| Cab | 群集 | Ra和Rb链接 | 1 | |||
必须对Ra与Rb一起管理的“信号”是出现至少一个这样的事务，该事务持有一个或多个处于争用中的资源并等待一个或多个其他处于争用下的资源。
在重新估算了它对拓扑的概观之后，Sy1(象以前一样)将它的概观广播到该群集中的其他系统。
1.Sy1、Ra、Cab、哑NQO值、本地。
2.Sy1、Rb、Cab、4、本地。
哑NQO值仅是一个比WLM可能生成的任何需求都要小的值。Sy1没有完全本地的NQO值，因为它没有本地等候者，但它确实需要发送必须根据它的本地数据将Ra和Rb作为一个单元进行管理的“虚拟消息”。
Sy2结合该数据(包括必须将Ra和Rb作为一个单元进行管理的事实，这意味着Ca与Cb必须合并)，生成以下各项。
| 系统Sy2 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cab | Ra | TxA(1) | 1 | |||
| Cab | Rb | TxC(5) | Sy1 | 4 | 4 | |
| Cab | 群集 | Sy1：Ra和Rb链接 | 1 | |||
现在，这两个系统在问题的重要之点(即需求最大的等候者的NQO值)上达成一致意见，即使这每一个系统都没有完整拓扑的副本。
在t＝10时，争用开始解除(Sy2：TxC释放Rb)。Sy2对Rb的概观现在只包括远程数据。
| 系统Sy1 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cab | Ra | TxB(4) | Sy2 | 1 | 1 | |
| Cab | Rb | TxB(4) | 4 | |||
| Cab | 群集 | Ra和Rb链接 | 1 | |||
| 系统Sy2 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cab | Ra | TxA(1) | 1 | |||
| Cab | Rb | Sy1 | 4 | 4 | ||
| Cab | 群集 | Sy1：Ra和Rb链接 | 1 | |||
在t＝11时，Sy1上的资源管理器实例发现Rb可用并将其给予其队列上的第一个等候者(Sy1：TxB被恢复并获得Rb)。由于资源管理器的等候队列现在为空，因此它通知WLM以指出Rb的争用已经结束。Sy1将Rb从它的资源群集中移除，因为在每一系统内，任何单个资源都只能属于单个群集(虽然由于时间窗口(timing window)，两个系统可能具有不同群集中的同一资源)。
| 系统Sy1 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Ca | Ra | TxB(4) | Sy2 | 1 | 1 | |
并行地，Sy2上的资源管理器实例被告知Rb不再被争用(根据资源管理器实现，这可能早在t＝10时便已发生了)，且它也将Rb从它的资源拓扑中移除。
| 系统Sy2 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Ca | Ra | TxA(1) | 1 | |||
在t＝12时，不存在变化，因为所释放的资源不再处于争用中(Sy1：TxB释放Rb)。
在t＝13时，争用完全解除(Sy1：TxB释放Ra)。Sy1上的资源管理器实例通知WLM，以便信号通知Ra的争用的结束。
| 系统Sy1 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
在t＝14时，Sy2也了解到争用的结束(Sy2：TxA被恢复并获得Ra(无争用))。Sy2上的资源管理器实例通知WLM，以便信号通知Ra的争用的结束。
| 系统Sy21 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
示例2(具有本地资源的传递闭包实例)
本示例是另一跨系统传递闭包实例：涉及不只一个资源，并且帮助持有一个资源的需求小的用户，以使等待不同资源的另一(需求大)用户前进。该拓扑也是多系统的，具有不同系统上的、相同资源的持有者和等候者。此外，与示例1形成对比的是，每一系统具有涉及相同事务的对完全本地(非多系统)资源的争用。这示出了当在同一资源群集中包括多系统和单系统资源两者时所发生的情况。
符号与示例1中的相同，除了多系统资源使用大写字母R(Ra、Rb)，而本地资源使用小写字母(rc、rd)。Rlocal(＝RL)是“对于远程系统来说在本地范围中的某一组不知名资源的”的代理名称。其实际值是无关紧要的，仅有的要求是所有的参与者对该值达成一致意见，并且不允许其与任何有效的资源名称相冲突。
在时间顺序上，事件序列如下：
| 时间(t) | 事件 |
| 1 | 无争用 |
| 2 | Sy1：TxB获得Ra。 |
| 3 | Sy2：TxC获得Rb。 |
| 4 | Sy1：TxB获得rl。 |
| 5 | Sy2：TxA获得rj。 |
| 6 | Sy1：TxB请求Rb，并由于TxC持有它而被暂停。 |
| 7 | Sy2：TxA请求Ra，并由于TxB持有它而被暂停。 |
| 8 | Sy1：TxS请求rl，并由于TxB持有它而被暂停。 |
| 9 | Sy2：TxT请求rj，并由于TxA持有它而被暂停。 |
| 10 | Sy2：TxC释放Rb。 |
| 11 | Sy1：TxB被恢复并获得Rb。 |
| 12 | Sy1：TxB释放Rb。 |
| 13 | Sy1：TxB释放Ra。 |
| 14 | Sy2：TxA被恢复并获得Ra(无多系统争用)。 |
| 15 | Sy1：TxB释放rl。 |
| 16 | Sy1：TxS被恢复并获得rl。 |
| 17 | Sy2：TxA释放rj。 |
| 18 | Sy2：TxT被恢复并获得rj。 |
在t＜8时，每一系统上的争用状态与示例1中的完全相同，因此，这里不再描述。
在t＝8时，对本地(非多系统)资源rl形成争用(Sy1：TxS请求rl，并由于TxB持有它而暂停)。资源rl仅被结合到Sy1上的资源群集中。rl的NQO是来自TxS的3，但群集Cab1仍然具有由于Ra而为1的NQO。
| 系统Sy1 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cab1 | Ra | TxB(4) | Sy2 | 1 | 1 | |
| Cab1 | Rb | TxB(4) | 4 | |||
| Cab1 | rl | TxB(4) | TxS(3) | 3 | ||
| Cab1 | 群集 | Ra、Rb、rl链接 | 1 | |||
当Sy1广播它对该群集的概观时，它不会直接广播rl，因为Ra和Rb是该群集中仅有的对其他系统可见的资源。而是，它将广播Sy1的所有本地资源(我们知道只有rl)的代理(Rlocal)。
1.Sy1、Ra、Cabl、哑NQO值、本地。
2.Sy1、Rb、Cabl、4、本地。
3.Sy1、Rlocal、Cabl、3、本地。
在接收到该数据并更新其拓扑之后，Sy2认为以下是其状态。
| 系统Sy2 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| CabL | Ra | TxA(1) | 1 | |||
| CabL | Rb | TxC(5) | Sy1 | 4 | 4 | |
| CabL | Rlocal | Sy1 | 3 | 3 | ||
| CabL | 群集 | Sy1：Ra、Rb、Rlocal链接 | 1 | |||
在t＝9时，另一本地资源展现其他系统上的争用(Sy2：TxT请求rj，并由于TxA持有它而暂停)。图7B示出在t＝9之后的拓扑。
在Sy2上发生与在Sy1上所刚刚进行的相同的处理，然后，Sy2将它的数据广播到Sy1。 Sy2广播如下数据：
1.Sy2、Ra、CabL、1、本地。
2.Sy2、Rb、CabL、哑NQO值、远程。
3.Sy2、Rlocal、CabL、2、本地。
在上面的广播中，Sy2上的本地资源的代理名称是由群集名称隐式限定的，因为，如下面所指出的那样，代理是对于每一资源群集定义的，而不是仅对该系统群集作为一个整体而定义的。此外，只有对于Ra和Rlocal的广播包括布尔值“本地”，因为只有这两个资源可根据本地数据分配给共同群集。
| 系统Sy1 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cab1L | Ra | TxB(4) | Sy2 | 1 | 1 | |
| Cab1L | Rb | TxB(4) | 4 | |||
| Cab1L | Rl | TxB(4) | TxS(3) | 3 | ||
| Cab1L | Rlocal | Sy2 | 2 | 2 | ||
| Cab1L | 群集 | Ra、Rb、rl链接 | Sy2：Ra、Rb、Rlocal链接 | 1 | ||
| 系统Sy2 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| CabLj | Ra | TxA(1) | 1 | |||
| CabLj | Rb | TxC(5) | Sy1 | 4 | 4 | |
| CabLj | Rlocal | Sy1 | 3 | 3 | ||
| CabLj | Rj | TxA(1) | TxT(2) | 2 | ||
| CabLj | 群集 | Ra、Rb、rj链接 | Sy1：Ra、Rb、Rlocal链接1 | |||
没有理由不可以通过向Sy2上的Rlocal的“远程等候者信息”中添加“Sy2，2”项目，或向Sy2上的“本地系统信息.等候者”中添加哑事务来概括所有本地资源争用；上表示出的是没有这种优化。通过上述方法之一以确实使Rlocal概括本地状态数据很可能会使广播代码更加简单；然后，可生成具有多系统范围的Rlocal，且在该广播代码中将不需要特殊情况了。存在其他明显需要特殊情况的情形。实际上，必须允许每一个资源群集有一个Rlocal，而不仅仅是每一个系统有一个Rlocal。
在t＝10时，争用开始解除(Sy2：TxC释放Rb)。现在，Sy2对Rb的概观只包括远程数据。
| 系统Sy1 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cab1L | Ra | TxB(4) | Sy2 | 1 | 1 | |
| Cab1L | Rb | TxB(4) | 4 | |||
| Cab1L | rl | TxB(4) | TxS(3) | 3 | ||
| Cab1L | Rlocal | Sy2 | 2 | 2 | ||
| Cab1L | 群集 | Ra、Rb、rl链接 | Sy2：Ra、Rb、Rlocal链接 | 1 | ||
| 系统Sy2 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| CabLj | Ra | TxA(1) | 1 | |||
| CabLj | Rb | Sy1 | 4 | 4 | ||
| CabLj | Rlocal | Sy1 | 3 | 3 | ||
| CabLj | rj | TxA(1) | TxT(2) | 2 | ||
| CabLj | 群集 | Ra、Rb、rj链接 | Sy1：Ra、Rb、Rlocal链按 | 1 | ||
在t＝11时，Sy1上的资源管理器实例发现Rb可用，并将它给予其队列上的第一个等候者(Sy1：TxB被恢复并获得Rb)。由于资源管理器的等候队列现在为空，因此它通知WLM以指出Rb的争用已经结束。并行地，Sy2上的资源管理器实例被告知Rb不再被争用(根据资源管理器的实现，这可能早在t＝10时就已发生)。这两个系统都必须将Rb从它的资源群集中移除，因为在每一系统内，任何单个资源都只能属于单个群集。两个系统可能暂时由于时间窗口或永久由于资源拓扑而同时具有不同群集中的相同资源。当涉及到两个以上的系统时，出现了不对称拓扑的例子。
| 系统Sy1 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Ca1L | Ra | TxB(4) | Sy2 | 1 | 1 | |
| Ca1L | Rl | TxB(4) | TxS(3) | 3 | ||
| Ca1L | Rlocal | Sy2 | 2 | 2 | ||
| Ca1L | 群集 | Ra、rl链接 | Sy2：Ra、Rlocal链接 | 1 | ||
| 系统Sy2 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| CaLj | Ra | TxA(1) | 1 | |||
| CaLj | Rlocal | Sy1 | 3 | 3 | ||
| CaLj | rj | TxA(1) | TxT(2) | 2 | ||
| CaLj | 群集 | Ra、rj链接 | Sy1：Ra、Rlocal链接 | 1 | ||
在t＝12时，不存在变化，因为所释放的资源不再处于争用中(Sy1：TxB释放Rb)。
在t＝13时，多系统争用完全解除(Sy1：TxB释放Ra)。Sy1上的资源管理器实例通知WLM，以便信号通知Ra的争用的结束。
由于Sy1上的资源群集现在只包括本地资源和涉及多系统争用的远程本地资源的代理，所以也可将该代理从该群集中移除。由于Sy2还未被通知Ra的争用的结束，所以它仍然将其代理资源作为群集的一部分。
| 系统Sy1 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| C1 | rl | TxB(4) | TxS(3) | 3 | ||
| 系统Sy2 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| CaLj | Ra | TxA(1) | 1 | |||
| CaLj | Rlocal | Sy1 | 3 | 3 | ||
| CaLj | Rj | TxA(1) | TxT(2) | 2 | ||
| CaLj | 群集 | Ra、rj链接 | Sy1：Ra、Rlocal链接 | 1 | ||
在t＝14时，Sy2也看到争胜的结束(Sy2：TxA被恢复，且获得Ra)。Sy2上的资源管理器实例通知WLM，以便信号通知Ra的争用的结束。
| 系统Sy2 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cj | rj | TxA(1) | TxT(2) | 2 | ||
在t＝15时，对于一个本地资源的争用结束(Sy1：TxB释放rl)，且TxS被恢复。一旦资源管理器向Sy1通知了关于rl的争用已经结束，Sy1的拓扑便再次为空。
在t＝17时，最后的争用结束(Sy2：TxA释放rj)，且TxT被恢复。一旦资源管理器向Sy2通知了对于rj的争用已经结束，则Sy2的拓扑再次为空。
示例3：分解群集(BreakClul)
本示例涉及将资源群集分解为一些较小群集，而对于所涉及的任何资源都没有争用结束。链接Ra和Rb的事务被取消，但由于每一资源都具有其他等候者，所以这两个资源随后仍然处于争用中。符号与示例1中的相同。
以时间顺序的事件序列如下：
| 时间(t) | 事件 |
| 1 | 无争用 |
| 2 | Sy1：TxD获得Rb。 |
| 3 | Sy2：TxA获得Ra。 |
| 4 | Sy1：TxD请求Ra，并由于TxA持有它而被暂停。 |
| 5 | Sy1：TxB请求Ra，并由于TxA持有它而被暂停。 |
| 6 | Sy1：TxE请求Rb，并由于TxD持有它而被暂停。 |
| 7 | Sy2：TxC请求Rb，并由于TxD持有它而被暂停。 |
| 8 | Sy1：TxD被操作员取消或超时，并回退(取消)。 |
在t＜4时，不存在争用，因此在每一系统上都没有WLM争用数据。在时间t＝4与t＝7之间发生的事件已经包括在前面的例子中。
图7C示出在t＝7之后的拓扑。此时的状态数据如下：
| 系统Sy1 |
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cab | Ra | TxB(4)TxD(2) | 2 | |||
| Cab | Rb | TxD(2) | TxE(3) | Sy2 | 5 | 3 |
| Cab | 群集 | Ra、Rb链接 | 2 | |||
| 系统Sy2 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cab | Ra | TxA(1) | Sy1 | 2 | 2 | |
| Cab | Rb | TxC(5) | Sy1 | 3 | 3 | |
| Cab | 群集 | Sy1：Ra、Rb链接 | 2 | |||
当事务TxD(无论由于什么原因)在t＝8终止时，每一系统上的资源管理器实例移除TxD所具有的所有未完成的等待请求(Ra)，并释放所有其持有的资源(Rb)。一旦向WLM通知了这些拓扑变化，Sy1知道应该将资源群集Cab分解为两部分(Ca和Cb)。它之所以知道这一点，是因为Sy1在本地确定两者本来是链接的(并可看出这在本地不再真实)，且没有远程系统的数据表示它们必须被链接。但是，这两个资源仍然处于争用中。下次Sy1广播它的拓扑数据时，Sy2上的“Sy1：Ra、Rb链接”数据被移除，且Sy2也更新它的拓扑。假定WLM在资源管理器实例重新分配所有权之前实现所有这些，则所得到的状态为：
| 系统Sy1 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Ca | Ra | TxB(4) | 4 | |||
| Cb | Rb | TxE(3) | Sy2 | 5 | 3 | |
| 系统Sy2 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Ca | Ra | TxA(1) | Sy1 | 4 | 4 | |
| Cb | Rb | TxC(5) | Sy1 | 3 | 3 | |
因此，这意味着具有某种移除必须一起管理Ra和Rb的“记忆”的机制，而不是依赖于对于所涉及的某一个资源的争用的结束。其他一些可选机制如下：
1.Sy1显式发送数据以指出其不再认为所给定的资源群集是必须的。例如，发送：Ra、Ca、4、远程。当Sy2替换Sy1前面对于Ra的数据时，它不再查看来自Sy1的任何对于一起管理Ra和Rb的需求；如果Sy2没有其他对于保持该群集的“表决”，则Sy2可本地分解该群集。
2.Sy1的数据过时(因此如果其不被“立刻”替换便被删除)。这可能通过发送“生存时间”(TTL)值来实现，在该生存时间之后该数据将被接受者删除。此机制可为出故障系统、丢失信号、程序错误、恢复问题等提供一安全网。TTL还具有使得通信等待时间透明且不需要发送者和接受者对共同间隔达成一致意见的优点。
最强健的方案很可能是所有这三个方案。让全局性地信号通知争用结束的资源管理器处理本地删除“Ra”块的情况，以便不必坚持它足够长时间来发送“分解该群集”消息。如果对于资源的争用在本地结束而未在远程结束，且本地系统是表决强制非平凡群集被构建的那个系统，则让TTL值引发在远程系统上该群集的破坏。如果该群集需要分解，但争用未结束，则仍然有“Ra”块，且“分解该群集”的消息就是毕竟要发送的自然结果。示例4：分解群集(BreakClu2)
在本例中，只由共同持有者加入的资源群集可看作“n”个资源的一个群集或“n”个各一个资源的群集。此结果是令人惊讶的，因而值得证明。
符号与示例1中的相同。
以时间顺序的事件序列如下：
| 时间(t) | 事件 |
| 1 | 无争用 |
| 2 | Sy2：TxA获得Ra和Rb。 |
| 3 | Sy1：TxB请求Ra，并由于TxA持有它而被暂停。 |
| 4 | Sy1：TxC请求Ra，并由于TxA持有它而被暂停。 |
| 5 | Sy1：TxD请求Rb，并由于TxA持有它而被暂停。 |
| 6 | Sy1：TxE请求Rb，并由于TxA持有它而被暂停。 |
图7D示出在t＝6之后的拓扑。
直到t＝6的所发生的事件已包括在前面的例子中。这里让人感兴趣的是根据怎样对事物进行定义，可将此情形或者作为一个资源群集或者作为两个资源群集来对待。如果使用前面例子中的定义，即资源群集可由系统识别为具有作为一个资源的持有者和作为不同资源的等候者的同一事务(且然后在系统群集中所有系统之上将此认知汇总起来)，则上面的图表清楚地表示了两个资源群集而不是如可能期望的一个资源群集。
由于形成资源群集Cab没有价值，且在这样作时存在相关的开销(更精确地说，当决定是否应该分解一个群集时存在相关的开销)，所以此定义将持续使用。因此，与上面的图表所对应的状态数据为：
| 系统Sy1 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Ca | Ra | TxB(4)，TxC(5) | 4 | |||
| Cb | Rb | TxD(2)，TxE(1) | 1 |
| 系统Sy2 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Ca | Ra | TxA(3) | Sy1 | 4 | 4 | |
| Cb | Rb | TxA(3) | Sy1 | 1 | 1 | |
与此定义相关的固有的假设是当WLM试图帮助工作时，它将检查每一资源，并基于NQO值根据需要帮助持有者。如果此拓扑被看作为单个资源群集，则TxA将从群集Cab继承为1的NQO。将这作为两个群集对待，则WLM会断定：
1.Ca不需要帮助，因为持有者的为3的NQO比该资源群集的为4的NQO需求更大。
2.Cb需要帮助，因为该群集的为1的NQO比TxA的为3的NQO需求更大。
由于TxA最终继承为1的NQO，而不管此情境被作为一个还是两个群集来对待，所以可选择任何一个。由于对什么时候需要分解组合群集进行的测试使得管理两个“平凡”(单个资源)群集比管理单个组合群集效率更高，所以此实例被作为两个平凡资源群集来看待。
示例5：简单的三路情境(3wayEase)
本例是简单的三系统情境。它也是一个传递闭包实例，但其不对称拓扑强制这些系统跟踪没有来自资源管理器的本地等候者/持有者信息的资源。符号与示例1中的相同。
以时间顺序的事件序列如下：
| 时间(t) | 事件 |
| 1 | 无争用 |
| 2 | Sy2：TxB获得Ra。 |
| 3 | Sy3：TxC获得Rb。 |
| 4 | Sy1：TxA请求Ra，并由于TxB持有它而被暂停。 |
| 5 | Sy2：TxB请求Rb，并由于TxC持有它而被暂停。 |
| 6 | Sy3：TxC释放Rb。 |
| 7 | Sy2：TxB获得Rb。 |
| 8 | Sy2：TxB完成，释放Ra和Rb。 |
| 9 | Sy1：TxA获得Ra。 |
直到t＝5的所发生事件已包括在前面的例子中。图7E示出在t＝5之后的拓扑。此时的状态数据为：
| 系统Sy1 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cab | Ra | TxA(1) | 1 | |||
| Cab | Rb | Sy2 | 2 | 2 | ||
| Cab | 群集 | Sy2：Ra、Rb链接 | 1 | |||
| 系统Sy2 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cab | Ra | TxB(2) | Sy1 | 1 | 1 | |
| Cab | Rb | TxB(2) | 2 | |||
| Cab | 群集 | Ra、Rb链接 | 1 | |||
| 系统Sy3 |
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cab | Ra | Sy1 | 1 | 1 | ||
| Cab | Rb | TxC(3) | Sy2 | 2 | 2 | |
| Cab | 群集 | Sy2：Ra、Rb链接 | 1 | |||
这里使人感兴趣的是Sy3不涉及Ra，然而它跟踪有关Ra的至少某些数据，以便确定TxC的NQO应该为1(从Sy1上的TxA继承)。但这不会引起太多的困难：Sy1和Sy2不知道其他哪一个系统涉及Ra，这只是在所有系统已广播了它们最近的拓扑数据(其当然是一个移动的目标)之后“发现的”。这样，Sy1和Sy2无论怎样都必须广播它们的数据。另外的负担是Sy3必须簿记其从对等方接收的概要数据，但只要它仍不涉及Ra，则不会有任何复杂的基于事务的逻辑被调用。这可能通过广播该群集的NQO和导致该NQO的系统的身份来消除，但当再次将群集分解为较小部分时会出现某些问题。跟踪每一资源看起来是为我们可以看到导致正确的NQO的事物所付出的小的代价。
从该状态的解除如前面的例子中那样进行。
示例6：具有群集分解的三路情境(3wayBreakClu)
本示例是三系统传递闭包实例，其中大群集被分解为较小的群集，而没有任何“争用的结束”事件驱使我们。本例还示出具有资源的多个共享持有者的拓扑。符号与示例1中的相同。
以时间顺序的事件序列如下：
| 时间(t) | 事件 |
| 1 | 无争用 |
| 2 | Sy2：TxB获得共享的Ra。 |
| 3 | Sy2：TxD获得共享的Ra。 |
| 4 | Sy3：TxC获得Rb。 |
| 5 | Sy1：TxA请求Ra，并由于TxB持有它而被暂停。 |
| 6 | Sy2：TxB请求Rb，并由于TxC持有它而被暂停。 |
| 7 | Sy3：TxE请求Rb，并由于TxC持有它而被暂停。 |
| 8 | Sy3：TxC释放Rb。 |
| 9 | Sy2：TxB获得Rb。 |
| 10 | Sy2：TxB完成，释放Ra和Rb。 |
| 12 | Sy3：TxE获得Rb。 |
| 13 | Sy2：TxD释放Ra。 |
| 14 | Sy1：TxA获得Ra。 |
直到t＝7所发生的事件已包括在前面的例子中。如在前面的例子中，Sy3不涉及Ra，然而它跟踪有关Ra的至少某些数据。
图7F示出在t＝7之后的拓扑。此时的状态数据为：
| 系统Sy1 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cab | Ra | TxA(1) | 1 | |||
| Cab | Rb | Sy2Sy3 | 25 | 2 | ||
| Cab | 群集 | Sy2：Ra、Rb链接 | 1 | |||
| 系统Sy2 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cab | Ra | TxB(2)，TxD(4) | Sy1 | 1 | 1 | |
| Cab | Rb | TxB(2) | Sy3 | 5 | 2 | |
| Cab | 群集 | Ra、Rb链接 | 1 | |||
| 系统Sy3 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Cab | Ra | Sy1 | 1 | 1 | ||
| Cab | Rb | TxC(3) | TxE(5) | Sy2 | 2 | 2 |
| Cab | 群集 | Sy2：Ra、Rb链接 | 1 | |||
从这一状态的解除如在前面的例子中那样进行。此时，在t＝8和t＝9时的事件意味着资源群集Cab不再需要，且按照前面的例子，该群集在此情况下将被分解。因此，在t＝9之后，有图7G和下表中所示的状态：
| 系统Sy1 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Ca | Ra | TxA(1) | 1 | |||
| Cb | Rb | Sy3 | 5 | 5 | ||
| 系统Sy2 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Ca | Ra | TxB(2)，TxD(4) | Sy1 | 1 | 1 | |
| Cb | Rb | TxB(2) | Sy3 | 5 | 5 | |
| 系统Sy3 | ||||||
| 资源群集 | 资源名称 | 本地系统信息 | 远程等候者信息 | NQO | ||
| 持有者 | 等候者 | 系统名称 | NQO | |||
| Ca | Ra | Sy1 | 1 | 1 | ||
| Cb | Rb | TxE(5) | 5 | |||
如同前面的情况，即分解资源群集而没有对于所包括的任何一个资源的争用清除，可以看出单个事务(这里是TxB)可同时涉及两个不同的资源群集，只要它或者仅在持有或者仅在等待处于争用下的资源。它一等待任何处于争用下的资源，就必须将它或者持有或者等待的处于争用下的所有资源作为单个资源群集来管理。
数据结构
图8A-8H示出根据本发明的用于存储争用数据的一组可能的数据结构。
参照图8A，资源争用控制表(RCCT)802用于锚定(anchor)仅(或主要)对单个WLM子部件来说有兴趣的各项目。它包含：
1.对于资源群集组件(RCLU)806(图8B)的锚点804。
2.对于资源组件(RSRC)810(图8C)的锚点808。
3.对于事务表(TRXNT)814(图8F)的锚点812。
参照图8B，每一资源群集组件(RCLU)806包括与单个资源群集有关的数据。它包括：
1.群集ID 816。
2.群集NQO 818(该群集中所有资源中最小的)。
3.对于该群集中的资源的资源组件(RSRC)810(图8C)的锚点820。
参照图8C，每一资源组件(RSTC)810描述处于争用下的资源。它包括：
1.资源标志(fingerprint)/名称822。
2.资源NQO 824。(为了广播路径上的效率，可能希望保持本地/系统群集值分开；否则，这是系统群集NQO。)
3.到群集组件(RCLU)806(图8B)的指针826。
4.对于本地持有者的资源争用队列组件(RCQE)830(图8H)的锚点828。
5.对于本地等候者的资源争用队列组件(RCQE)830的锚点832。
6.对于有关该资源的远程数据的系统数据锚点(SDA)836(图8D)的锚点834。
参照图8D，每一系统数据锚点(SDA)836用作对于单个系统的远程系统信息的锚点。它包括：
1.远程系统ID 838。
2.从该系统对于远程系统数据组件(RSDE)842(图8E)的锚点840。
3.表示远程系统的最高已知发送顺序号的值844。换句话说，在外向路径上，发送系统包括一个对于每一“批”拓扑数据都相同的值(如时戳)。每一接收系统将进入的消息中的值与此值进行比较；如果该消息具有较低的值(意味着它是陈旧的，因为该接收系统已经从同一发送者接收到了更近的数据)，则该消息被忽略。
4.时戳846，当从远程系统接收到拓扑消息时，使用本地时钟将该时戳更新。
参照图8E，每一远程系统数据组件(RSDE)842包括资源的远程系统信息。它包括：
1.到系统的系统数据锚点(图8D)的指针848。
2.到资源的资源组件(RSRC)810(图8C)的指针850。
3.对于同一资源的其他RSDE 842的队列链接852。
4.远程系统的NQO 854，只考虑远程系统上的等候者。
5.仅用于调试的发送时戳856(在发送时的远程系统上的时钟值)。
6.表示接收到时的本地时钟值的用于调试和TTL处理的时戳858。
7.此资源的远程群集ID 860。如果远程系统具有既是持有者又是等候者的事务，则所涉及的所有资源在那里将具有相同的群集ID，且在这里需要处于同一群集中。如果来自不同系统的远程数据对于哪些资源属于一个群集意见不一致，则该些群集将在本地联合(union)。
8.由远程系统提供的生存时间(TTL)期间862，其对应于远程系统计划多长时间发送一次数据加一点额外时间。如果本地时间超过接收时戳加该值，则该组件适合于被删除。
参照图8F，事务表(TRNXT)814用于锚定仅(或主要)对于单个WLM子部件来说有兴趣的项目。它包括：
1.当该事务表814构建时的地址空间的数量864。
2.当该事务表814构建时的工作区域的数量866。
3.从该事务表的开始到第一个表项的偏移868。
4.用于身为地址空间的事务的表项(TRXNE)(最多达数量864)的区域870。
5.用于身为工作区域的事务的表项(TRXNE)(最多达数量866)的区域872。
参照图8G，事务表(TRXNT)814的区域870或872中的每一表项(TRXNE)874包括关于单个事务的信息，其中该单个事务涉及至少一个其争用正由WLM所管理的资源。它包括：
1.类型876：地址空间或工作区域。
2.这一事务的地址空间ID(ASID)或工作区域ID 878。
3.这一事务的地址空间或工作区域令牌880。ASID和工作区域ID可重新使用；令牌提供在单个映象内的唯一性，即使这些ID是重新使用的。
4.由这一事务持有的资源的争用组件(RCQE)830(图8H)的队列884的锚点882。
5.由这一事务等待的资源的争用组件(RCQE)830的队列888的锚点。
6.这一事务的NQO 888。
参照图8H，每一资源争用队列组件(RCQE)830将事务(持有者或等候者)与资源相关。它包括：
1.在TRXNT 810中的事务的TRXNE 874的偏移892。
2.这一事务的下一个/上一个RCQE 830的队列链接894。
3.到资源的资源组件(RSRC)810的指针896。
4.这一资源的下一个/上一个RCQE 830的队列链接898。
5.持有/等待位899(很可能仅用于队列验证)。
图9示出图8A-8H中所示的各种数据结构怎样捕获在图4中所示的和伴随着图4说明的表中对于Sy2所概括的争用情境。
尽管已经示出和描述了特定实施例，各种修改对于本领域的技术人员来说是显而易见的。因此，不是(根据本地或远程争用数据)对于被认为是共同群集的一部分的所有资源发送共同群集ID，而是本地系统可以仅对于那些根据本地争用数据已知属于共同群集的资源使用共同群集ID。还有其他一些变换对于本领域的技术人员来说是显而易见的。
Claims (20)
1.一种用于管理用户之间对于访问包括多个系统的系统群集中的一个或多个资源的争用的方法，每一所述用户具有所指派的需求并且能够作为其正寻求访问的资源的持有者或等候者，所述方法在作为本地系统的至少一个所述系统上执行，并且包括以下步骤：
存储本地群集数据，该本地群集数据指示根据所述本地系统上的争用而将所述资源分为一个或多个本地群集的分组，并对于每一个所述本地群集指示用于所述本地群集中的一个或多个资源的需求；
从作为远程系统的、所述系统群集中的另一个系统接收远程群集数据，该远程群集数据指示根据所述远程系统上的争用而将所述资源分为一个或多个远程群集的分组，并对于每一个所述远程群集指示用于所述远程群集中的一个或多个资源的需求；
组合所述本地群集数据和所述远程群集数据，以生成组合群集数据，该组合群集数据指示根据所述各系统之上的争用而将所述资源分为一个或多个组合群集的分组，并对于每一个所述组合群集指示用于该组合群集中的一个或多个资源的需求；以及
根据一个所述组合群集的组合群集数据，管理该群集中的资源的、所述本地系统上的持有者。
2.权利要求1的方法，其中所述用于任何一个所述群集中的一个或多个资源的需求是该群集中对于任何资源的需求最大的等候者的需求。
3.权利要求1的方法，其中所述管理步骤包括以下步骤：
识别未在等候任何其他资源的、一个所述组合群集中的资源的、所述本地系统上的持有者；以及
将系统资源分配给所述本地系统上的所述资源的所述持有者，就好像它的需求至少是所述组合群集中的任何资源的需求最大的等候者的需求。
4.权利要求1的方法，其中所述接收步骤对于作为远程系统的、所述系统群集中的多个其他系统中的每一个来执行。
5.权利要求1的方法，其中如果所述本地系统上的一用户在等待另一资源的时候正持有一个资源，则所述本地系统将该对资源分配给一共同的本地群集。
6.权利要求1的方法，其中所述本地系统响应于接收到有关所述本地系统上的用户的、资源争用状态中的变化的通知，更新所述本地群集数据。
7.权利要求6的方法，其中所述本地系统将更新后的本地群集数据传送给所述远程系统。
8.权利要求1的方法，其中所述本地系统在从所述远程系统接收到远程群集数据时，更新所述组合群集数据。
9.权利要求1的方法，其中所述本地系统将本地群集数据传送到所述远程系统。
10.权利要求9的方法，其中上述传送的本地群集数据指示资源、根据本地系统上的争用而被分配了该资源的群集、及所述本地系统上用于所述资源的需求。
11.一种用于管理用户之间对于访问包括多个系统的系统群集中的一个或多个资源的争用的装置，每一所述用户具有所指派的需求并且能够作为其正寻求访问的资源的持有者或等候者，所述装置与作为本地系统的至少一个所述系统相关，并且包括：
用于存储本地群集数据的逻辑，该本地群集数据指示根据所述本地系统上的争用而将所述资源分为一个或多个本地群集的分组，并对于每一个所述本地群集指示用于所述本地群集中的一个或多个资源的需求；
用于从作为远程系统的、所述系统群集中的另一系统接收远程群集数据的逻辑，该远程群集数据指示根据所述远程系统上的争用而将所述资源分为一个或多个远程群集的分组，并对于每一个所述远程群集指示用于所述远程群集中的一个或多个资源的需求；
用于组合所述本地群集数据和所述远程群集数据，以生成组合群集数据的逻辑，该组合群集数据指示根据所述各系统之上的争用而将所述资源分为一个或多个组合群集的分组，并对于每一个所述组合群集指示用于该组合群集中的一个或多个资源的需求；以及
用于根据一个所述组合群集的组合群集数据，管理该群集中的资源的、所述本地系统上的持有者的逻辑。
12.权利要求11的装置，其中所述管理逻辑包括：
用于识别未在等待任何其他资源的、一个所述组合群集中的资源的、所述本地系统上的持有者的逻辑；以及
用于将系统资源分配给所述本地系统上的所述资源的所述持有者，就好像它的需求至少是所述组合群集中的任何资源的需求最大的等候者的需求的逻辑。
13.权利要求11的装置，其中如果所述本地系统上的一用户在等待另一资源的时候正持有一个资源，则所述本地系统将该对资源分本地配给一共同的本地群集。
14.权利要求11的装置，其中所述本地系统响应于接收到有关所述本地系统上的用户的、资源争用状态中的变化的通知，更新所述本地群集数据并将更新后的本地群集数据传送给所述远程系统。
15.权利要求11的装置，其中所述本地系统将本地群集数据传送给所述远程系统，所传送的本地群集数据指示资源、根据本地系统上的争用而被分配了该资源的群集、及在所述本地系统上用于所述资源的需求。
16.一种机器可读的程序存储装置，其有形地体现可由该机器执行以执行用于管理用户之间对于访问包括多个系统的系统群集中的一个或多个资源的争用的方法步骤的指令程序，每一所述用户具有所指派的需求并且能够作为其正寻求访问的资源的持有者或等候者，所述方法步骤在作为本地系统的一个所述系统上执行，且包括：
存储本地群集数据，该本地群集数据指示根据所述本地系统上的争用而将所述资源分为一个或多个本地群集的分组，并对于每一个所述本地群集指示用于所述本地群集中的一个或多个资源的需求；
从作为远程系统的、所述系统群集中的另一系统接收远程群集数据，该远程群集数据指示根据所述远程系统上的争用而将所述资源分为一个或多个远程群集的分组，并对于每一所述远程群集指示用于所述远程群集中的一个或多个资源的需求；
组合所述本地群集数据和所述远程群集数据，以生成组合群集数据，该组合群集数据指示根据所述系统之上的争用而将所述资源分为一个或多个组合群集的分组，并对于每一个所述组合群集指示用于该组合群集中的一个或多个资源的需求；以及
根据一个所述组合群集的组合群集数据，管理该群集中的资源的、所述本地系统上的持有者。
17.权利要求16的程序存储装置，其中所述管理步骤包括以下步骤：
识别未在等待任何其他资源的、一个所述组合群集中的资源的、所述本地系统上的持有者；以及
将系统资源分配给所述本地系统上的所述资源的所述持有者，就好像它的需求至少是所述组合群集中的任何资源的需求最大的等候者的需求。
18.权利要求16的程序存储装置，其中如果所述本地系统上的用户在等待另一资源的时候正持有一个资源，则所述本地系统将该对资源分配给一共同的本地群集。
19.权利要求16的程序存储装置，其中所述本地系统响应于接收到有关所述本地系统上的用户的资源争用状态中的变化的通知，更新所述本地群集数据并将更新后的本地群集数据传送给所述远程系统。
20.权利要求16的程序存储装置，其中所述本地系统将本地群集数据传送给所述远程系统，所传送的本地群集数据指示资源、根据本地系统上的争用而被分配了该资源的群集、及在所述本地系统上用于所述资源的需求。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/334,203 US7228351B2 (en) | 2002-12-31 | 2002-12-31 | Method and apparatus for managing resource contention in a multisystem cluster |
| US10/334,203 | 2002-12-31 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1711523A true CN1711523A (zh) | 2005-12-21 |
| CN1331052C CN1331052C (zh) | 2007-08-08 |
Family
ID=32654967
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB2003801030057A Expired - Fee Related CN1331052C (zh) | 2002-12-31 | 2003-11-14 | 用于管理多系统群集中资源争用的方法和装置 |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US7228351B2 (zh) |
| JP (1) | JP4370260B2 (zh) |
| KR (1) | KR100834432B1 (zh) |
| CN (1) | CN1331052C (zh) |
| AU (1) | AU2003300229A1 (zh) |
| WO (1) | WO2004066148A1 (zh) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101346678B (zh) * | 2005-12-30 | 2011-06-22 | 先进微装置公司 | 用于丛集工具的自动化状态估计系统以及操作该系统的方法 |
| CN101375250B (zh) * | 2006-02-03 | 2012-01-04 | 甲骨文国际公司 | 用于管理数据库系统中锁定请求的方法 |
| CN103813481A (zh) * | 2013-09-23 | 2014-05-21 | 杭州优能通信系统有限公司 | 一种智能终端设备及其业务处理方法 |
| CN109753485A (zh) * | 2018-12-07 | 2019-05-14 | 新华三云计算技术有限公司 | 一种磁盘锁管理方法及装置 |
Families Citing this family (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6658423B1 (en) * | 2001-01-24 | 2003-12-02 | Google, Inc. | Detecting duplicate and near-duplicate files |
| US7284018B1 (en) * | 2003-10-15 | 2007-10-16 | Sun Microsystems, Inc. | Logless transaction coordination |
| JP3896111B2 (ja) * | 2003-12-15 | 2007-03-22 | 株式会社日立製作所 | リソース割り当てシステム、方法及びプログラム |
| US7680970B2 (en) * | 2004-10-22 | 2010-03-16 | Fisher-Rosemount Systems, Inc. | Method and system for batch process arbitration in a process control system |
| US7739314B2 (en) * | 2005-08-15 | 2010-06-15 | Google Inc. | Scalable user clustering based on set similarity |
| KR100898454B1 (ko) | 2006-09-27 | 2009-05-21 | 야후! 인크. | 통합 검색 서비스 시스템 및 방법 |
| KR101156618B1 (ko) * | 2008-11-21 | 2012-06-14 | 연세대학교 산학협력단 | 무선 네트워크에서 자원을 할당하는 방법 |
| US8510739B2 (en) | 2010-09-16 | 2013-08-13 | International Business Machines Corporation | Shared request grouping in a computing system |
| US9317329B2 (en) * | 2010-11-15 | 2016-04-19 | Qualcomm Incorporated | Arbitrating resource acquisition for applications of a multi-processor mobile communications device |
| US8577885B2 (en) | 2010-12-09 | 2013-11-05 | International Business Machines Corporation | Partitioning management of system resources across multiple users |
| US20120151163A1 (en) | 2010-12-09 | 2012-06-14 | International Business Machines Corporation | Management of host passthrough and session commands using resource groups |
| US8793286B2 (en) | 2010-12-09 | 2014-07-29 | International Business Machines Corporation | Hierarchical multi-tenancy management of system resources in resource groups |
| US8484655B2 (en) | 2010-12-09 | 2013-07-09 | International Business Machines Corporation | Management of copy services relationships via policies specified on resource groups |
| US9094394B2 (en) | 2012-01-23 | 2015-07-28 | Microsoft Technology Licensing, Llc | Managing cross-premises resources through integrated view |
| CN103905250B (zh) * | 2014-03-21 | 2018-02-23 | 浪潮电子信息产业股份有限公司 | 一种优化管理集群状态的方法 |
| US9569280B2 (en) * | 2014-09-15 | 2017-02-14 | Seagate Technology Llc | Managing resource collisions in a storage compute device |
| US10257053B2 (en) | 2016-06-28 | 2019-04-09 | International Business Machines Corporation | Analyzing contention data and following resource blockers to find root causes of computer problems |
| US11222297B2 (en) * | 2019-11-21 | 2022-01-11 | Rockspoon, Inc. | System and method for matching patrons, servers, and restaurants within the food service industry |
Family Cites Families (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5197130A (en) | 1989-12-29 | 1993-03-23 | Supercomputer Systems Limited Partnership | Cluster architecture for a highly parallel scalar/vector multiprocessor system |
| US5339427A (en) | 1992-03-30 | 1994-08-16 | International Business Machines Corporation | Method and apparatus for distributed locking of shared data, employing a central coupling facility |
| US5444693A (en) | 1992-04-27 | 1995-08-22 | At&T Corp. | System for restoration of communications networks |
| US5719868A (en) | 1995-10-05 | 1998-02-17 | Rockwell International | Dynamic distributed, multi-channel time division multiple access slot assignment method for a network of nodes |
| US5805900A (en) * | 1996-09-26 | 1998-09-08 | International Business Machines Corporation | Method and apparatus for serializing resource access requests in a multisystem complex |
| US6151688A (en) * | 1997-02-21 | 2000-11-21 | Novell, Inc. | Resource management in a clustered computer system |
| US6038651A (en) | 1998-03-23 | 2000-03-14 | International Business Machines Corporation | SMP clusters with remote resource managers for distributing work to other clusters while reducing bus traffic to a minimum |
| US6330612B1 (en) * | 1998-08-28 | 2001-12-11 | International Business Machines Corporation | Method and apparatus for serializing access to a shared resource in an information handling system |
| US6189007B1 (en) * | 1998-08-28 | 2001-02-13 | International Business Machines Corporation | Method and apparatus for conducting a high performance locking facility in a loosely coupled environment |
| US6732166B1 (en) * | 1999-05-28 | 2004-05-04 | Intel Corporation | Method of distributed resource management of I/O devices in a network cluster |
| US6631406B1 (en) | 1999-06-03 | 2003-10-07 | Fujitsu Network Communications, Inc. | Common management information base (MIB) |
| US6442564B1 (en) | 1999-06-14 | 2002-08-27 | International Business Machines Corporation | Facilitating workload management by using a location forwarding capability |
| WO2001018650A2 (en) * | 1999-09-03 | 2001-03-15 | General Instrument Corporation | Resource access control system |
| US6681242B1 (en) * | 2000-01-10 | 2004-01-20 | Sun Microsystems, Inc. | Method and apparatus for detecting dependency cycles between resources in a computer system |
| JP2002057699A (ja) * | 2000-08-11 | 2002-02-22 | Nec Corp | パケット伝送方式、パケット伝送方法及び記録媒体 |
| US6889253B2 (en) * | 2001-04-30 | 2005-05-03 | International Business Machines Corporation | Cluster resource action in clustered computer system incorporation prepare operation |
| US7047299B1 (en) * | 2001-08-31 | 2006-05-16 | Hewlett-Packard Development Company, L.P. | Generic cluster aware lock broker with user defined locking modes |
| US7392390B2 (en) * | 2001-12-12 | 2008-06-24 | Valve Corporation | Method and system for binding kerberos-style authenticators to single clients |
| US7444634B2 (en) * | 2002-10-31 | 2008-10-28 | Sun Microsystems, Inc. | Method and apparatus for providing dynamic locks for global resources |
-
2002
- 2002-12-31 US US10/334,203 patent/US7228351B2/en not_active Expired - Fee Related
-
2003
- 2003-11-14 AU AU2003300229A patent/AU2003300229A1/en not_active Abandoned
- 2003-11-14 KR KR1020057009822A patent/KR100834432B1/ko not_active IP Right Cessation
- 2003-11-14 WO PCT/EP2003/014865 patent/WO2004066148A1/en active Application Filing
- 2003-11-14 JP JP2004566814A patent/JP4370260B2/ja not_active Expired - Fee Related
- 2003-11-14 CN CNB2003801030057A patent/CN1331052C/zh not_active Expired - Fee Related
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101346678B (zh) * | 2005-12-30 | 2011-06-22 | 先进微装置公司 | 用于丛集工具的自动化状态估计系统以及操作该系统的方法 |
| CN101375250B (zh) * | 2006-02-03 | 2012-01-04 | 甲骨文国际公司 | 用于管理数据库系统中锁定请求的方法 |
| CN103813481A (zh) * | 2013-09-23 | 2014-05-21 | 杭州优能通信系统有限公司 | 一种智能终端设备及其业务处理方法 |
| CN109753485A (zh) * | 2018-12-07 | 2019-05-14 | 新华三云计算技术有限公司 | 一种磁盘锁管理方法及装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| AU2003300229A1 (en) | 2004-08-13 |
| US20040128385A1 (en) | 2004-07-01 |
| WO2004066148A1 (en) | 2004-08-05 |
| JP4370260B2 (ja) | 2009-11-25 |
| KR20050088366A (ko) | 2005-09-05 |
| US7228351B2 (en) | 2007-06-05 |
| KR100834432B1 (ko) | 2008-06-04 |
| CN1331052C (zh) | 2007-08-08 |
| JP2006512688A (ja) | 2006-04-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1711523A (zh) | 用于管理多系统群集中资源争用的方法和装置 | |
| CN1284095C (zh) | 多处理器系统中的任务分配方法和多处理器系统 | |
| CN1256671C (zh) | 管理资源争用的方法和装置 | |
| CN100347696C (zh) | 企业业务过程管理的方法和系统 | |
| CN1280716C (zh) | 计算机处理方法、分布式计算方法和网络计算方法 | |
| CN1143208C (zh) | 用于消息转换的装置和方法 | |
| CN1175341C (zh) | 异步更新共享资源的接口系统和方法 | |
| CN1783086A (zh) | 用于在数据库管理系统中的查询管理的系统和方法 | |
| CN1130656C (zh) | 对一个存储文件的若干文件拷贝进行协调的方法 | |
| CN1677979A (zh) | 通过网络在计算机之间共享对象的系统和方法 | |
| CN101044498A (zh) | 工作流服务体系结构 | |
| CN1993674A (zh) | 多芯架构中的资源管理 | |
| CN1303497A (zh) | 采用实时调度逻辑和时间确定结构的分布式计算环境 | |
| CN1777107A (zh) | 高性能计算(hpc)系统中的按需式例示 | |
| CN1858759A (zh) | 对网络游戏用户进行时间限制的方法和系统 | |
| CN1122216C (zh) | 优化器 | |
| CN1776622A (zh) | 高性能计算(hpc)系统中的调度式 | |
| CN1906583A (zh) | 信息处理设备、中断处理控制方法、以及计算机程序 | |
| CN1795654A (zh) | 网络环境中的内容同步系统及其方法 | |
| CN1167020C (zh) | 数据共享方法和终端 | |
| CN1729442A (zh) | 在网络中使用共享资源的方法和装置 | |
| CN1292529A (zh) | 管理计算环境的分区组的方法,系统和程序产品 | |
| CN1174319C (zh) | 数据结构管理装置、数据结构管理系统和方法 | |
| CN1734438A (zh) | 信息处理设备、信息处理方法和程序 | |
| CN1113292C (zh) | 可由多个用户单元同时使用的程序进行的访问控制的方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20070808 Termination date: 20151114 |
|
| EXPY | Termination of patent right or utility model |