CN1514366A - 管理资源争用的方法和装置 - Google Patents
管理资源争用的方法和装置 Download PDFInfo
- Publication number
- CN1514366A CN1514366A CNA2003101215958A CN200310121595A CN1514366A CN 1514366 A CN1514366 A CN 1514366A CN A2003101215958 A CNA2003101215958 A CN A2003101215958A CN 200310121595 A CN200310121595 A CN 200310121595A CN 1514366 A CN1514366 A CN 1514366A
- Authority
- CN
- China
- Prior art keywords
- resource
- cluster
- user
- resources
- needs
- 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
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multi Processors (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
一种方法和装置，其用来管理访问一个多系统群集中的资源的用户之间对资源的争用，其方法是识别争用链，其中每个用户在等待一个在该链中处于它之前的用户持有的资源，并把系统资源分配给在该链中打头的用户，如同它们的需求至少是该链中最有需求的等待者的需求。为最佳资源分配所必须的争用数据被有效地跨系统群集分发，即使在系统间的数据流是极小的，而且没有一个系统具有跨系统争用的完全视图。每个系统跟踪处于争用中的、具有本地用户作为持有者或等待者的资源，并把这些资源分组成争用链中涉及的资源群集，在这些群集中的每个资源或者由等待该群集中另一资源的本地用户所持有，或者由持有该群集中另一资源的本地用户所等待。
Description
技术领域
本发明涉及一种方法和装置，用于在信息管理系统中管理那些访问串行化资源的用户之间对资源的争用。
背景技术
资源争用是信息管理系统中的公知现象。当一个用户(例如一个进程或其他工作单元)试图访问一个已被另一用户持有的资源，而且这第二个用户所请求的访问与第一个用户请求的访问不一致时，便会发生资源争用。例如，如果其中任何一个用户在请求对所考虑的资源进行排他性访问时，就将发生这种情况。资源管理器是软件组件，它们管理竞争的请求者对它们控制的资源的争用，其作法是允许一个或多个这样的用户作为持有者访问该资源，而把其余的所有用户放在等待者池中直至该资源变为可用时为止。
在具有多个资源管理器和多个工作单元的计算机操作系统，如IBMz/OSTM操作系统中，资源争用管理是一个复杂的问题。争用链能够形成，或换句话说，争用能跨越资源。例如，作业A等待资源R1但持有R2，而作业B持有R1但在等待R3，而R3又被作业R3持有。争用能跨越系统。在上例中，每个作业可以在一个单独系统上。争用可以跨越资源管理器。例如R1能是一个GRS队列，而R2能是一个DB2TM闩锁。z/OS的全局资源串行化(GRS)组件管理队列，而IMSTM资源锁管理器(IRLM)另行管理DB2资源。
通常是通过追踪每个资源的持有者和等待者的拓扑关系和找出任何交会点，在单个资源管理器(如GRS)内解决跨资源争用。通常是通过使资源管理器知道整个群集的数据(把群集作为一个单元而不是作为各独立系统来管理)来解决跨系统争用。通常是让一个报告产品查询全部接口并使数据相关，如同它是一个虚拟资源管理器，以此“解决”跨资源管理器的争用。因为该问题是争用资源个数的O(2n)量级，所以它在计算上也是复杂的。
z/OS的基本MVSTM组件有一个简单有效的解决方案(通常称作“队列促进”(enqueue promotion))：自动地(和暂时地)促进持有被报告为处于争用状态的资源的任何工作单元对CPU和MPL的访问，并不注意该工作单元的需要。这等效于管理一个持有者，如同存在对一资源的“重要”请求者，而不管实际的拓扑关系如何。为理解这一操作，考虑下述举例。假定：
1.作业A持有资源R1。
2.作业B持有资源R2并等待R1。
3.作业C等待R2。以符号表示，这能表示为一个链C→B→A，这里大写字母代表作业，符号“→”(链中的“链接”)表明符号左边的作业在等待符号右边的作业所持有的资源。这样，上述链意味着作业C等待由作业B持有的资源，而作业B又在等待由作业A持有的资源。
假定这些资源是GRS资源，传统的MVS实现将会帮助作业A和B，因为它们持有处于争用状态的资源，等同地并在有限时间内促进每个作业。然而，帮助B没什么好处，因为事实上B在等待A。如果B本身是多任务的，则这种帮助在实际上可能伤害竞争的工作而关于资源争用没有做任何事情。
发明内容
本发明的一个方面，这是本申请的主题，包括一个方法和装置，用于管理那些访问信息管理系统中的资源的用户之间对资源的争用，在该信息管理系统中每个用户有被赋予的需求，并且能是它正寻求访问的资源的持有者或等待者。根据本发明的这一方面，识别在用户链中打头的不是等待者的用户，在该用户链中每个在该链中有下一个用户的用户持有其下一个用户正在等待的资源。管理该链中打头的那个用户，如同它的需求至少是该链中最有需求的等待者的需求，其优选的作法是把系统资源分配给该用户，如同它的需求至少是这种最有需求的等待者的需求。
优选地，并作为本发明这一方面的一个独立的发明特性，通过识别出一个资源群集，其中，该群集中的每个资源或者由等待该群集中另一个资源的一个用户所持有，或者由持有该群集中另一资源的一个用户所等待，并通过确定该群集中任何资源的最有需求的等待者的需求，以此来识别这样的争用链。识别出一个用户，它是该群集中一个资源的持有者并且不是在等待任何其他资源，并管理该资源的那个持有者，如同它的需求至少是对该群集中任何资源的最有需求的等待者的需求，再次地其优选的作法是把系统资源分配给该用户，如同它的需求至少是这种最有需求的等待者的需求。
优选地，识别群集的步骤是对收到一个资源争用状态变化的通知作出响应而进行的。这样，如果一个资源现在被等待一个群集中另一资源的用户所持有或者被持有该群集中另一资源的用户所等待，则该资源便被重新赋予该群集。另一方面，如果一个资源不再被等待一个群集中另一资源的用户所持有或者不再被持有该群集中另一资源的用户所等待，则该资源便被从该群集中去掉。
这样，本发明的这一方面企图把“需求”因子集成到基本系统资源分配机制中，从而使在链中打头的作业(如上述作业A，其需求因子为4)能够运行，如同它的需求因子是该链上别处的一个更有需求的作业的需求因子(例如上述作业C，其需求因子为1)，直至它释放该资源为止。把需求的概念加到先前的例子中，人们能更好地理解它的表现有何不同。假定：
1.具有“需求”4的作业A持有资源R1。(在这一说明书中，较低的数字表示较大的需求，所以它们能被认为是“求助优先级”。)
2.具有需求5的作业B持有资源R2并等待R1。
3.具有需求1的作业C等待R2。以符号表示，这能表示为C(1)→B(5)→A(4)，这里大写字母代表作业，括号内的数字代表那些作业的“需求”，而符号“→”(链中的“链接”)表明符号左边的作业在等待符号右边的作业所持有的资源。这样，上述链意味着具有需求1的作业C等待由具有需求5的作业B持有的资源，而作业B又在等待由具有需求4的作业A持有的资源。
以这种方式使用“需求”因子给出若干可能是非显而易见的好处。首先，它避免帮助如上述B那样的作业，因为我们理解B也是在等待另一资源，从而避免了一个行动，该行动最好情况下是无用的，而最坏情况下会伤害无关的竞争作业。第二，它给予系统资源分配器以知识，从而允许它给予A更多的否则它不会给予的帮助，而且是无限期地帮助，而不是只在有限时间内帮助。尽管传统的实现会忽略该链并在某一有限时间段把A和B二者作为“重要的”作业对待，但在本发明中，所理解的是，只要C在等待，A实际上便有需求1，或者说是“最重要的”。第三，它给予系统资源分配器以知识，从而允许它在希望时放弃帮助在该链中打头的持有者，例如，如果在网络中的最有需要的作业是当前持有者的话。
本发明的该第一方面或者可以在单一系统上实现，或者可以在含有多个这种系统的群集上实现。本发明的能识别资源群集的变体特别适于在多系统实现中使用，因为它只需局部争用数据的一个子集的交换，如下文中描述的那样。
本发明的另一方面，其是上文标出的同时提交的申请的主题，构想一个协议用于跨多个系统管理资源分配，而只需传送极少量数据，其数量约为争用的多系统资源数的O(n)量级。
本发明的这另一方面加入了上述单系统发明的诸方面，其构想一个方法和装置用于管理访问含有多个系统的系统群集中的资源的那些用户之间的争用，每个用户有被赋予的需求，而且能是它正寻求访问的资源的持有者或等待者。根据本发明的这一方面，每个作为本地系统运行的这样的系统存储本地群集数据，该数据指明基于该本地系统上的争用把资源分组到本地群集中，并为每个本地群集指明对该本地群集中一个或多个资源的需求。每个系统还从该系统群集中作为远程系统运行的其他系统中接收远程群集数据，该数据为每个这样的远程系统指出基于该远程系统上的争用把这些资源分组到远程群集，并为每个远程群集指出对该远程群集中一个或多个资源的需求。每个本地系统把本地群集数据与远程群集数据组合以产生合成群集数据，该数据指出根据跨系统争用把资源分组到合成群集，并为每个合成群集指出对该合成群集中一个或多个资源的需求。于是，每个本地系统使用这一合成群集数据管理在该本地系统上的对合成群集中资源的持有者。
优选地，本地的、远程的和合成的群集数据指出等待所考虑的群集中的任何资源的最有需要的等待者的需求，并且对本地系统上的合成群集中资源的持有者，是通过识别出不等待任何其他资源的持有者并把系统资源分配给这样的持有者，如同它们的需求至少是对相应合成群集中任何资源最有需求的等待者的需求，以此来进行管理。
优选地，每个本地系统将一对资源赋予一个共同的本地群集，如果该本地系统上的一个用户在持有其中一个资源而在等待其中另一个资源的话，并且响应接收到与该本地系统上的用户有关的一个资源争用状态变化的通知，更新该本地群集数据。每个本地系统还把它的本地群集数据，包括任何更新，传送给远程系统，这些远程系统把被传送的群集数据作为相对于接收系统的远程群集数据对待，然后相应地更新它们的合成群集数据。被传送的本地群集数据指出一个资源、根据在该本地系统上的争用该资源被赋予的群集以及在该本地系统上对该资源的需求。
使用来自该群集中每个参加的资源管理器实例的部分数据(不是全部资源拓扑)和“需求”的量度，每个系统能单个地理解对于一个资源的最有需要的等待者(包括跨“上述任何事物”资源的传递闭合(transitiveclosure)中的任何等待者)是否比该链中打头的任何资源持有者更有需求。然后，该系统能把资源分配给这样的持有者，如同它们的需求量度不小于最有需求的被阻塞的一个作业的需求。
该协议每个资源只传送一组信息，而不是来自每个系统的全部持有者和等待者的列表，从而没有任何系统具有跨越群集的争用的完全视图。该数据本身只包括：群集唯一的资源名、在该发送系统上的最有需求的等待者的需求值以及发送系统唯一的令牌。如果后面的令牌与两个资源匹配，则必须纳入对它们的管理(只根据发送系统的本地数据赋予令牌)。该协议还只发送处于争用中的资源的数据，即使该拓扑中的一些作业持有未被争用的其他资源。发送系统的群集信息能以各种方式编码。这样，不是发送只基于该发送系统上的本地争用的一个令牌，而是如在一个优选实施例中那样，该本地系统能发送也基于远程争用的一个群集名，并带有一个指示以说明一个非平凡的群集赋予(即向一个含有不只一个资源的群集赋予)是基于本地的还是基于远程的信息。
优选地，本发明作为一个计算机操作系统的一部分实现，或者作为与这种操作系统联合工作的“中间件”软件来实现。这样的软件实现包括指令程序形式的逻辑，这些指令可由硬件机器执行，以实现本发明的方法步骤。该指令程序可以体现在由使用半导体、磁、光或其他存储技术的一个或多个卷组成的程序存储设备上。
附图说明
图1显示包含本发明的计算机系统群集。
图2A-2D显示各类争用链。
图3显示向在争用链中打头的用户分配资源的过程。
图4显示在若干系统上的事务和资源当中的典型争用场景。
图5显示响应来自一个本地资源管理器的通知之后进行的一般过程。
图6显示响应接收到来自一个远程系统的争用数据广播之后进行的一般过程。
图7A-7G显示在各种运行实例中的多系统争用状态。
图8A-8H显示在本发明的一个实施例中用于存储争用数据的各种数据结构。
图9显示如何由该群集的系统之一捕获图4中所示争用场景。
具体实施方式
图1显示包含本发明的计算机系统群集100。群集100包括单个系统(Sy1、Sy2、Sy3)，它们由任何适当类型的互连104连接在一起。尽管所示例子有三个系统，但本发明并不限于任何特定的系统数量。群集100有一个或多个全局的或多系统的资源106，它们被来自各系统的请求者争用。
该群集的每个系统102包括一个单独的物理机器或者一个或多个物理机器的一个单独的逻辑分区。每个系统包括一个操作系统(OS)108，它除了实现本发明的功能外，还实现提供系统服务和管理系统资源的使用的通常的功能。尽管本发明不限于任何特定的硬件或软件平台，但优选地，每个系统102包括一个IBM z/OS操作系统实例，其运行在一个IBMzSeriesTM服务器上或这种服务器的一个逻辑分区上。
每个系统102包括一个或多个请求者110，它们彼此竞争对多系统资源106的访问以及可选地对本地资源112的访问，这些本地资源只对该同一系统上的请求者可用。请求者110可以包括任何实体，它竞争对资源106或112的访问，并且被作为单个实体对待以分配系统资源。
(分配给请求者110的系统资源应与资源106及112区分开，资源106和112是在请求者之间争用的对象。系统资源通常是以对请求者本身透明的方式分配给请求者110，以改进某些性能指标，如吞吐量或响应时间。而另一方面，资源106和112是由请求者作为它们的执行过程的一部分明确请求的。当需要区分它们的时候，后一类资源有时使用术语“串行化资源”或类似术语来称呼。)
每个操作系统108包括若干个对本发明有意义的组件，包括一个或多个资源管理器114和工作负荷管理器(WLM)116。
每个资源管理器114通过允许一个或多个竞争的请求者作为持有者访问资源106或112，而把其余的请求者都放在等待者池中直至该资源变为可用时为止，以此来管理诸竞争请求者110之间对它控制的资源106或112的争用。尽管本发明不限于任何特定的资源管理器，但一个这样的资源管理器(用于多系统资源106)可以是z/OS操作系统的全局资源串行化(GRS)组件，该组件在诸如IBM出版物“z/OS MVS计划：全局资源串行化”，(z/OS MVS planning：Global Resource Serialization)，SA 22-7600-02(2002年3月)的参考文献中作了描述，该文献在这里被纳入作为参考。再有，尽管资源管理器114被描述为操作系统108的一部分(如同GRS是z/OS的一部分)，但其他资源管理器(如IRLM)可以独立于操作系统而存在。
工作负荷管理器(WLM)116根据“需求”值把系统资源分配给工作单元(它可以是地址空间、飞地(enclave)等)，该“需求”值被赋予那个工作单元(或它所属的服务类别)，并在某种意义上反映了那个工作单元相对于被处理的其他工作单元的相对优先级。尽管本发明不限于任何特定的工作负荷管理器，但一个这样的工作负荷管理器是IBM z/OS操作系统的工作负荷管理组件，该组件在IBM出版物“z/OS MVS计划：工作负荷管理”，(z/OS MVS Planning：Workload Management)SA22-7602-04(2002年10月)，和z/OS MVS编程：工作负荷管理服务”(z/OS MVSProgramming：Workload Management Services)，SA22-7619-03(2002年10月)中描述的那样，这两篇文献在这里被纳入作为参考。这样的工作负荷管理组件与IBM z/OS操作系统的系统资源管理器(SRM)构件联合工作，如在IBM出版物z/OS MVS初始化和调优指导(z/OS MVSInitialization and Tuning Guide)，SA22-7591-01(2002年3月)，特别是第3章(3-1至3-84页)中描述的那样，该文献在这里被纳入作为参考。因为这些组件相互作用的特定方式不是本发明的组成部分，这两个组件假定由图1中标为“VLM”的框116引用。
不论是向用户赋予需求值的特定方式还是根据所赋予的需求值向用户分配系统资源的方式都不是本发明的组成部分。本领域多种已知技术中的任何技术都能用作这两种方式。优选地，需求值应是跨越该系统群集有相似意义的值。在所示实施例中，它是根据现行WLM策略计算出来的动态值，它把资源组限制和重要性集成为能跨越系统安全地进行比较的单个量。尽管排序是任意的，但在本描述中较低的数值代表较高的需求和优先级，于是具有需求“1”的用户比具有需求“5”的用户“更有需求”。
图2A-2C显示在系统群集100中的资源106和112当中可能发生的各种争用链。这些链更正式的称呼是有向图(directed graph)，但这里将使用术语“链”。在这些链中的每个链接(用箭头表示)代表一个关系，其中一个用户(由箭头尾部的节点代表)在等待由另一用户(由箭头头部的节点代表)持有的资源。这种关系的“传递闭合”是通过这样的方法所形成的链，即把涉及该链任何节点的所有这些关系都包括在内，从而当遵循这些箭头时，所有节点最终将指向一个持有者，其不是在等待处于争用中的任何资源并因此站在该链的开头。(下文在图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)中最有需求者的需求。
在上述所有实例中，争用链是无环的(acyclic)，意思是不能通过沿链接箭头方向跟踪链接来形成闭合路径。如果有这样的闭合路径，则会有资源死锁，只能通过终止该死锁中涉及的一个或多个用户来打破这一死锁。
现在转到详细描述一个多系统实现，图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 | cluster(群集) | 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。尽管描述的是步骤的一特定序列，但该序列的顺序可以改变，只要当进行每一步骤时能得到必要的输入数据。
过程500开始于当WLM实例从一个本地资源管理器接收一个通知，表明与本地用户有关的资源争用状态发生变化。这种变化可以表明下列中的任何一个：
1.一个本地用户已变成由另一用户持有的一个资源的等待者。
2.一个本地用户不再是一个资源的等待者。这或者是因为它已作为持有者获取了该资源，或者是因为无论作为该资源的持有者或等待者，它对该资源已不再有兴趣(可能因为它已终止，所以不再存在，如下文的一个实例中描述的那样)。
3.由一个本地用户持有的一个资源现在处于争用状态。
4.由一个本地用户持有的一个资源不再处于争用状态。
来自本地资源管理器的通知会标识该资源以及本地持有者和等待者。在一个优选实施例中，WLM从没有单独显示出来的SRM组件得到这些持有者和等待者各自的“需求”(它们的固有需求，不是根据本发明被改变的需求)；但是这一数据的特定来源不是本发明的组成部分。
响应从资源管理器实例接收到这样的通知，WLM的本地实例首先更新所考虑的资源的本地争用数据(步骤504)。这种更新可包括为该本地系统上新被争用的资源创建一个新的条目，修改该本地系统上已经处于争用状态的资源的现有条目，或者删除该本地系统上不再处于争用状态的资源的现有条目。这一本地争用数据包括持有或等待该资源的任何本地用户的标识以及这个用户的“需求”。
在更新本地争用数据之后，WLM的本地实例在必要时更新该资源的群集赋予(步骤506)。默认时，一个资源被赋予一个平凡的群集，它只包括它自己作为成员。如果这种赋予是由本地争用数据或远程争用数据要求的话，则一个资源被赋予一个非平凡的群集，其包括至少一个其他资源。根据本地争用数据，一个资源被赋予一个含有另一资源的群集，如果那本地争用数据表明同一个本地用户在持有其中一个资源而同时在等待另一个资源的话，就是说，如果该资源被等待另一资源的用户所持有或者由持有另一资源的用户所等待的话。根据远程争用数据，一个资源被赋予一个含有另一资源的群集，如果那远程争用数据表明至少一个远程系统已根据相对于那个远程系统为本地的争用数据把这两个资源赋予一个共同的群集的话。这样，这一群集赋予步骤可能涉及：(1)对该资源的群集赋予不作改变；(2)如果改变了的本地争用数据和任何现有的远程争用数据要求这种赋予的话，把该资源新赋予一个非平凡的群集；或者(3)如果改变了的本地争用数据和任何现有的远程争用数据不再要求这种赋予的话，则打破一个现有的群集。如果该资源的群集赋予被改变，则此时受这一改变影响的其他资源的群集信息也被类似地修改。
同时地，WLM的本地实例更新该资源的一个被转嫁的“需求”值，该值只是基于该资源的本地争用数据(步骤508)。这一被转嫁的需求是该资源的任何本地等待者的需求中最大的一个，如该资源的本地争用数据指出的那样。尽管这一步骤被显示为跟随在群集赋予步骤之后，但步骤的顺序是不重要的，因为没有一个步骤使用另一步骤的结果。
在WLM的本地实例已更新该资源的群集赋予和被转嫁的需求值之后的某一点，该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实例的远程争用数据广播(步骤602)，由WLM的本地实例遵循的一般过程600。这一广播对于每个受影响的资源包括步骤512的描述中列出的信息。
响应接收这样的一通知，WLM的本地实例首先对所考虑的资源更新其远程争用数据(步骤604)。如步骤304中描述的对本地争用数据的更新那样，这种更新能包括为在本地系统上新处于争用状态的资源创建新的条目，为在本地系统上已处于争用状态的资源修改现有条目，或为在本地系统上不再处于争用状态的资源删除现有条目。这种远程争用数据包括具有对该资源的等待者的任何远程系统的一个标识，以及在该远程系统上对该资源的最有需求的等待者的需求。
在为该资源更新其远程争用数据之后，WLM的本地实例更新该资源的合成群集数据，如它在步骤510中做的那样。如在步骤510中那样，更新的合成群集包括：(1)基于本地和远程争用数据二者的该资源的被转嫁需求值；(2)根据本地和远程争用数据，将资源分组到一个合成群集；以及(3)基于本地和远程争用数据的、该资源群集作为一个整体的被转嫁的“需求”值(步骤606)。
最后，如在步骤514中那样，本地WLM实例对本地用户的“需求”值做任何必要的调整，其方法是调整不同时是另一资源的等待者的任何本地的资源持有者(因而它处在一个争用链的开头)的“需求”，从而使这一“需求”至少与含有该资源的群集中最有需求的等待者的固有需求匹配(步骤608)。
详细的举例和场景说明如下：
例1(“简单的”传递闭合案例)
这一举例是跨系统的传递闭合案例：它涉及不只一个资源，持有一个资源的无需求用户得到帮助，以使等待另一资源的另一个(有需求的)用户运动。该拓扑是多系统的，同一资源的持有者和等待者处在不同的系统上。
这一案例显示当在同一资源群集中只涉及多系统资源时发生的情况，所以它是“简单的”传递闭合案例。
在这一实例中的符号表示如下。每个持有者和等待者是一事务(Txn，例如TxA、TxB)，并具有NQO(eNQueue Order，队列顺序)值。NQO的取值是使较小值为更有需求者(更值得帮助)。每个系统都被编号(Sy1、Sy2)，而且所有这些系统都在同一个“系统群集”中。每个资源有一个小写字母(Ra、Rb)，而且其范围是多系统的。每个资源群集有一个或多个小写字母(Ca、Cab)，显示该群集中的资源列表。获取资源的请求是请求排他性控制，除非另有说明。
事件序列按时间顺序列于下表：
| 时间(t) | 事件 |
| 1 | 无争用 |
| 2 | Sy1：TxB获得Ra。 |
| 3 | Sy2：TxC获得Rb。 |
| 6 | Sy1：TxB请求Rb并被挂起，因为TxC持有Rb。 |
| 7 | Sy2：TxA请求Ra并被挂起，因为TxB持有Ra。 |
| 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持有Rb)。结果，Sy1：
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的NQO，其为Cb中所有资源NQO的最有需求者。这把NQO 4从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上运行的资源管理器实例把对Rb的争用通知给Sy2。操作顺序没有关系，但它们将按前述顺序列出。代码中的唯一“技巧”是：如果Sy2上的资源管理器赢得这场比赛，则当该远程数据到达时该代码必须认识到它已经构建了同一群集并把该远程信息加到它的现有数据中。
在从Sy1接收远程信息之后，Sy2上的状态如下：
| 系统Sy2 | ||||||
| 资源群集 | 资源名 | 本地系统信息 | 远程等待者信息 | NQO | ||
| 持有者 | 等待者 | 系统名 | NQO | |||
| Cb | Rb | Sy1 | 4 | |||
一旦Sy2的本地资源管理器把对Rb的争用通知给Sy2，则Sy1和Sy2上的状态如下：
| 系统Sy1 | ||||
| 资源 | 资源名 | 本地系统信息 | 远程等待者信息 | NQO |
| 群集 | 持有者 | 等待者 | 系统名 | NQO | ||
| Cb | Rb | TxB(4) | 4 |
| 系统Sy2 | ||||||
| 资源群集 | 资源名 | 本地系统信息 | 远程等待者信息 | NQO | ||
| 持有者 | 等待者 | 系统名 | NQO | |||
| Cb | Rb | TxC(5) | Sy1 | 4 | 4 | |
请注意，在Sy2上的、Rb的本地NQO是4，不是5，5是TxC的NQO。首先，资源持有者的NQO从不影响资源的NQO；由于该持有者在运行，WLM的策略调整代码已经隐含地使用了这个NQO。其次，Sy2现在知道，在该系统群集中的某个其他地方有一个NQO为4的事务正在等待；由于4被定义为比5更有需求，所以Rb的NQO必须不比4需求更小。
在t＝7，在另一资源上产生争用(Sy2：TxA请求Ra并被挂起，因为TxB持有Ra)。图7A显示t＝7之后的拓扑。
由于资源Ra也有多系统范围，这造成与刚才对Rb发生的情况类似的一些握手，其结果状态如下：
| 系统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上的资源管理器实例把对Ra的争用通知给Sy1，则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，因为在每个系统内任何单个资源只能属于单个群集(尽管由于计时窗口不同两个系统可能会有同一资源处在不同的群集中)。
| 系统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的争用结束。
| 系统Sy2 | ||||||
| 资源群集 | 资源名 | 本地系统信息 | 远程等待者信息 | NQO | ||
| 持有者 | 等待者 | 系统名 | NQO | |||
例2(具有本地资源的传递闭合案例)
这个实例是另一个跨系统传递闭合案例：不只一个资源被涉及，持有一个资源的无需求用户必须得到帮助，以使等待另一资源的另一个(有需求的)用户运动。该拓扑又是多系统的，同一资源的诸持有者和等待者处在不同的系统上。此外，与例1不同的是，每个系统具有涉及这些相同事务的对纯本地(非多系统)资源的争用。这显示出当同一资源群集中涉及多系统和单系统二种资源时会发生的情况。
表示符号与例1中相同，只是多系统资源使用大写R(Ra、Rb)而本地资源使用小写r(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持有Rb。 |
| 7 | Sy2：TxA请求Ra并被挂起，因为TxB持有Ra。 |
| 8 | Sy1：TxS请求rl并被挂起，因为TxB持有rl。 |
| 9 | Sy2：TxT请求rj并被挂起，因为TxA持有rj。 |
| 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)。资源rl只被纳入Sy1上的资源群集。由TxS得到的、rl的NQO为3，但由于Ra，群集Cabl仍有NQO为1。
| 系统Sy1 | ||||||
| 资源群集 | 资源名 | 本地系统信息 | 远程等待者信息 | NQO | ||
| 持有者 | 等待者 | 系统名 | NQO | |||
| Cabl | Ra | TxB(4) | Sy2 | 1 | 1 | |
| Cabl | Rb | TxB(4) | 4 | |||
| Cabl | Rl | TxB(4) | TxS(3) | 3 | ||
| Cabl | 群集 | Ra、Rb、rl被链接 | 1 | |||
当Sy1广播它的群集视图时，它并不直接广播rl，因为仅有Ra和Rb是该群集中能由其他系统看到的资源。代替地，它将为Sy1的所有本地资源(我们知道这只是rl)广播一个代理(Rlocal)。
1.Sy1，Ra，Cabl，伪NQO值，本地。
2.Sy1，Ra，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持有rj)。图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 | |||
| CablL | Ra | TxB(4) | Sy2 | 1 | 1 | |
| CablL | Rb | TxB(4) | 4 | |||
| CablL | Rl | TxB(4) | TxS(3) | 3 | ||
| CablL | Rlocal | Sy2 | 2 | 2 | ||
| CablL | 群集 | 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被链接 | Sy2：Ra、Rb、Rlocal被链接 | 1 | ||
人们没有理由不能通过对Sy2上的Rlocal的“远程等待者信息”添加“Sy2，2”条目或对Sy2上的“本地系统信息。等待者”添加伪事务来概括全部本地资源争用；上表中显示没有这一优化。让Rlocal通过上述方法之一概括本地状态数据可能会使广播代码更简单；于是Rlocal能以多系统范围产生并且在广播代码中无需特例。存在其他案例，在那里清楚地需要有特例。事实上人们必须允许每个资源群集有一个Rlocal，而不只是每个系统有一个。
在t＝10，争用开始解开(Sy2：TxC释放Rb)。现在Sy2的Rb视图只含有远程数据。
| 系统Sy1 | ||||||
| 资源群集 | 资源名 | 本地系统信息 | 远程等待者信息 | NQO | ||
| 持有者 | 等待者 | 系统名 | NQO | |||
| CablL | Ra | TxB(4) | Sy2 | 1 | 1 | |
| CablL | Rb | TxB(4) | 4 | |||
| CablL | Rl | TxB(4) | TxS(3) | 3 | ||
| CablL | Rlocal | Sy2 | 2 | 2 | ||
| CablL | 群集 | 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 | |||
| CalL | Ra | TxB(4) | Sy2 | 1 | 1 | |
| CalL | rl | TxB(4) | TxS(3) | 3 | ||
| CalL | Rlocal | Sy2 | 2 | 2 | ||
| CalL | 群集 | 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 | ||
| Cl | rl | TxB(4) | TxS(3) | 3 |
| 系统Sy2 | ||||||
| 资源群集 | 资源名 | 本地系统信息 | 远程等待者信息 | NQO | ||
| 持有者 | 等待者 | 系统名 | NQO | |||
| CaLj | Ra | TxA(1) | 1 | |||
| CaLj | Rlocal | Sy1 | 3 | 3 | ||
| CaLj | rj | TxA(1) | TxA(2) | 2 | ||
| CaLj | 群集 | Ra、rj被链接 | Sy1：Ra、Rlocal被链接 | 1 | ||
在t＝14，Sy2也看到争用结束(Sy2：TxA被恢复并获得Ra)。Sy2上的资源管理器实例通知WLM，告知Ra的争用结束。
| 系统Sy1 | ||||||
| 资源群集 | 资源名 | 本地系统信息 | 远程等待者信息 | 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，告知对rl的争用已经结束，Sy2的拓扑再次成为空的。
例3：打破一个群集(打破Clu1)
这一举例涉及把一个资源群集打破成较小的群集，而没有对所涉及的任何资源结束争用。链接Ra和Rb的事务被取消，但由于每个资源有其他等待者，在此后这两个资源仍处于争用状态。表示符号与例1中相同。
事件序列按时间顺序列于下表：
| 时间(t) | 事件 |
| 1 | 无争用 |
| 2 | Sy1：TxD获得Rb。 |
| 3 | Sy2：TxA获得Ra。 |
| 4 | Sy1：TxD请求Ra并被挂起，因为TxA持有Ra。 |
| 5 | Sy1：TxB请求Ra并被挂起，因为TxA持有Ra。 |
| 6 | Sy1：TxE请求Rb并被挂起，因为TxD持有Rb。 |
| 7 | Sy2：TxC请求Rb并被挂起，因为TxD持有Rb。 |
| 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(5) | 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：打破一个群集(打破Clu2)
在这一举例中，只由共同持有者联系起来的一个资源群集能被作为“n”个资源的一个资源群集或者作为每个群集有一个资源的“n”个群集来对待。
表示符号与例1相同。
事件序列按时间顺序列于下表：
| 时间(t) | 事件 |
| 1 | 无争用 |
| 2 | Sy2：TxA获得Ra和Rb。 |
| 3 | Sy1：TxB请求Ra并被挂起，因为TxA持有Ra。 |
| 4 | Sy1：TxC请求Ra并被挂起，因为TxA持有Ra。 |
| 5 | Sy1：TxD请求Rb并被挂起，因为TxA持有Rb。 |
| 6 | Sy1：TxE请求Rb并被挂起，因为TxA持有Rb。 |
图7D显示t＝6之后的拓扑关系。
至t＝6为止所发生的事件已在前例中包括。这里有意思的是，取决于如何定义，人们可以把这一情况作为一个资源群集或者两个资源群集来对待。如果我们使用前几个举例中的定义，即一个资源群集能被标识为一个系统有同一个事务作为一个资源的持有者而且作为一个不同资源的持有者(并在该系统群集中的所有系统上汇总一知识)，那么显然上述图示描述两个资源群集而不是可能预期的一个群集。
由于形成资源群集Cab没有价值，而且在这样做时存在开销(更确切地说，在确定一个群集是否要被打破时涉及到开销)，这一定义将继续被使用。所以，与上述图示对应的状态数据应该是：
| 系统Sy1 | ||||||
| 资源群集 | 资源名 | 本地系统信息 | 远程等待者信息 | NQO | ||
| 持有者 | 等待者 | 系统名 | NQO | |||
| Ca | Ra | TxB(4)，TxC(5) | 4 | |||
| Cb | Rb | TxD(2)，TxE(1) | ||||
| 系统Sy2 | ||||||
| 资源群集 | 资源名 | 本地系统信息 | 远程等待者信息 | NQO | ||
| 持有者 | 等待者 | 系统名 | NQO | |||
| Ca | Ra | TxA(3) | Sy1 | 4 | 4 | |
| Cb | Rb | TxA(3) | Sy1 | 1 | 1 | |
这一定义的内在假定是，当WLM试图帮助作业时，它将检验每个资源，并根据其NQO值给予持有者必要的帮助。如果这一拓扑被作为单一的资源群集对待，则TxA将从群集Cab继承一个NQO值1。如果作为两个群集对待，则WLM应得出如下结论：
1.Ca不需要帮助，因为持有者的NQO3，比资源群集的NQO4更有需求。
2.Cb需要帮助，因为群集的NQO1，比TxA的NQO3更有需求。
由于不论这一场景是作为一个还是两个资源群集对待，TxA最后都继承NQO值1，所以我们能选择二者中的任何一个。管理两个“平凡的”(单个资源的)群集比管理单个合成群集更有效，这是由于需要测试何时应分解该合成群集，因此，这一案例被作为两个平凡的资源群集对待。例5：简单的三向场景(3wayEasy)
这个例子是简单的三系统场景。它也是一个传递闭合案例，但它的非对称性拓扑关系迫使系统去跟踪那些没有来自资源管理器的本地等待者/持有者信息的资源。表示符号与例1中相同。
事件序列按时间顺序列于下表：
| 时间(t) | 事件 |
| 1 | 无争用 |
| 2 | Sy2：TxB获得Ra。 |
| 3 | Sy3：TxC获得Rb。 |
| 4 | Sy1：TxA请求Ra并被挂起，因为TxB持有Ra。 |
| 5 | Sy2：TxB请求Rb并被挂起，因为TxC持有Rb。 |
| 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被链接 | ||||
| 系统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被链接 | ||||
这里有意思的是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持有Ra。 |
| 6 | Sy2：TxB请求Rb并被挂起，因为TxC持有Rb。 |
| 7 | Sy3：TxE请求Rb并被挂起，因为TxC持有Rb。 |
| 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用于锚定只是(或主要是)对于单个WLM子组件来说有兴趣的各种项目。它包括：
1.锚点804，其用于资源群集元素(RCLU)806(图8B)。
2.锚点808，其用于资源元素(RSRC)810(图8C)。
3.锚点812，其用于一个事务表(TRXNT)814(图8F)。
参考图8B，每个资源群集元素(RCLU)806含有与单个资源群集有关的数据。它包括：
1.群集ID 816。
2.群集NQO 818(在该群集中所有资源的最小值)。
3.锚点820，其用于该群集中资源的资源元素(RSRC)810(图8C)。
参考图8C，每个资源元素(RSRC)810描述处于争用中的资源。它包括：
1.资源指纹/名822。
2.资源NQO 824。(人们可能为提高在广播路径上的效率而把本地/系统群集值保持分开；否则这是系统群集NQO)。
3.到群集元素(RCLU)806(图8B)的指针826。
4.锚点828，其用于本地持有者的资源争用队列元素(RCQE)830(图8H)。
5.锚点832，其用于本地等待者的资源争用队列元素(RCQE)830。
6.锚点834，其用于诸系统数据锚点(SDA)836(图8D)，这些系统数据锚点(SDA)836是用于关于这一资源的远程数据的。
参考图8D，每个系统数据锚点(SDA)836用作一单个系统的远程系统信息的锚点。它包括：
1.远程系统ID 838。
2.锚点840，其用于来自这一系统的诸远程系统数据元素(RSDE)842(图8E)。
3.值844，代表该远程系统的最高已知发送序列号。换言之，在外出通路上发送系统包括一个值(类似于时间戳)，其对每一“批”拓扑数据是相同的。每个接收系统将进入消息中的值与这一值做比较；如果该消息有一个较低的值(意味着该消息是陈旧的，因为接收系统已经从同一发送者接收了更晚的数据)，于是该消息被忽略。
4.时间戳846，当从该远程系统接收一个拓扑消息时使用本地时钟对其更新。
参考图8E，每个远程系统数据元素(RSDE)842包括一个资源的远程系统信息。它包括：
1.到该系统的系统数据锚点(SDA)(图8D)的指针848。
2.到该资源的资源元素(RSRC)810(图8C)的指针850。
3.同一资源的其他RSDE 842的队列链接852。
4.远程系统的NQO 854，只考虑该远程系统上的等待者。
5.发送时间戳856(当被发送时在远程系统上的时钟值)，只用于查错。
6.时间戳858，代表当被接收时的本地时钟值，其用于查错和TTL处理。
7.用于这一资源的远程群集ID 860。如果该远程系统有一个事务既是持有者又是等待者，则所涉及的所有资源将在那里有相同的群集ID，并在这里需要处在同一群集。如果来自不同系统的远程数据对于哪些资源属于一个群集不一致，则这些群集被在本地合并。
8.寿命(TTL)持续时间862，其由远程系统提供，对应于该远程系统计划多长时间发送数据加上一点额外值。如果本地时间大于接收时的时间戳加上这个值，则该元素适于删除。
参考图8F，事务表(TRXNT)814用于锚定只是(或主要是)对于单个WLM子组件来说有兴趣的各种项目。它包括：
1.当构建该事务表814时的地址空间数864。
2.当构建该事务表814时的飞地(enclave)数866。
3.从事务表起始到第一个表条目868的偏移量868。
4.用于这样的事务的条目(TRXNE)(可达个数864)的区域870，那是地址空间。
5.用于这样的事务的条目(TRXNE)(可达个数866)的区域872，那是飞地。
参考图8G，在事务表(TRXNT)814的区域870或872中的每个条目(TRXNE)874包括关于单个事务的信息，该事务涉及至少一个资源，该资源的争用由WLM管理。条目874包括：
1.类型876：地址空间或飞地。
2.这一事务的地址空间ID(ASID)或飞地ID 878。
3.这一事务的地址空间或飞地令牌880。ASID和飞地ID是可重用的；即使当这些ID重用时，也能由令牌提供一单个映像内的唯一性。
4.对于由这一事务持有的资源的争用元素(RCQE)830(图8H)的队列884的锚点882。
5.对于由这一事务等待的资源的争用元素(RCQE)830(图8H)的队列884的锚点886。
6.这一事务的NQO 888。
参考图8H，每个资源争用队列元素(RCQE)830使一个事务(持有者或等待者)与一资源关联。它包括：
1.该事务的TRXNE 874在TRXNT 810中的偏移量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.权利要求3的方法，其中所述管理步骤包括如下步骤：
确定对所述群集中任何资源的最有需求的等待者的需求。
5.一种用于对在一信息管理系统中访问一个或多个资源的用户之间的资源争用进行管理的方法，每个所述用户有被赋予的需求并且能够是它正寻求访问的资源的持有者或等待者，所述方法包括如下步骤：
识别所述资源的群集，其中，在该群集中的每个资源或者由等待该群集中另一资源的一个用户所持有，或者由持有该群集中另一资源的一个用户所等待；
确定对所述群集中任何资源的最有需求的等待者的需求；
识别所述群集中一个资源的持有者，它不在等待任何其他资源；以及
管理所述资源的所述持有者，如同它的需求至少是对所述群集中任何资源的所述最有需求的等待者的需求。
6.权利要求5的方法，其中所述管理步骤包括如下步骤：
把系统资源分配给所述资源的所述持有者，如同它的需求至少是对所述群集中任何资源的所述最有需求的等待者的需求。
7.权利要求5的方法，其中所述识别一个群集的步骤是对收到一个资源的争用状态变化的通知作出响应而进行的，并包括如下步骤：
如果一个资源现在被等待一个群集中另一资源的一用户所持有或者现在被持有该群集中另一资源的一用户所等待，则把该资源新赋予该群集。
8.权利要求5的方法，其中所述识别一个群集的步骤是对收到一个资源的争用状态变化的通知作出响应而进行的，并包括如下步骤：
如果一个资源不再被等待一个群集中另一资源的一用户所持有或者不再被持有一个群集中另一资源的一用户所等待，则从该群集中去掉该资源。
9.一种用于对在一信息管理系统中访问一个或多个资源的用户之间的资源争用进行管理的装置，每个所述用户有被赋予的需求并且能够是它正寻求访问的资源的持有者或等待者，所述装置包括：
识别逻辑，用于识别在用户链中打头的不是一个等待者的用户，在所述用户链中，每个在所述链中有下一个用户的用户持有由所述下一个用户正在等待的资源；以及
管理逻辑，用于管理在所述链中打头的所述用户，如同它的需求至少是所述链中所述最有需求者的需求。
10.权利要求9的装置，其中所述管理逻辑把系统资源分配给在所述链中打头的所述用户，如同它的需求至少是所述链中所述最有需求的等待者的需求。
11.一种用于对在一信息管理系统中访问一个或多个资源的用户之间的资源争用进行管理的装置，每个所述用户有被赋予的需求并且能够是它正寻求访问的资源的持有者或等待者，所述装置包括：
识别逻辑，用于识别所述资源的群集，其中，在该群集中的每个资源或者由等待该群集中另一资源的一个用户所持有，或者由持有该群集中另一资源的一个用户所等待；
确定逻辑，用于确定所述群集中任何资源的最有需求的等待者的需求；
识别逻辑，用于识别所述群集中一个资源的持有者，该持有者不在等待任何其他资源；以及
管理逻辑，用于管理所述资源的所述持有者，如同它的需求至少是所述群集中任何资源的所述最有需求的等待者的需求。
12.权利要求11的装置，其中所述管理逻辑把系统资源分配给所述资源的所述持有者，如同它的需求至少是所述群集中任何资源的所述最有需求的等待者的需求。
13.权利要求11的装置，其中所述用于识别群集的逻辑对收到一个资源争用状态变化的通知作出响应，把该资源新赋予该群集，如果该资源现在被等待该群集中另一资源的用户所持有或者现在被持有该群集中另一资源的用户所等待的话。
14.权利要求11的装置，其中所述用于识别群集的逻辑对收到一个资源争用状态变化的通知作出响应，从一群集中去掉该资源，如果该资源不再被等待该群集中另一资源的用户所持有或者不再被持有该群集中另一资源的用户所等待的话。
15.一种机器可读的程序存储设备，其有形地体现可由该机器执行的指令程序，用于执行方法步骤以对在一信息管理系统中访问一个或多个资源的用户之间的资源争用进行管理，每个所述用户有被赋予的需求并且能够是它正寻求访问的资源的持有者或等待者，所述方法包括步骤：
识别在一用户链中打头的不是一个等待者的用户，在所述用户链中，每个在所述链中有下一个用户的用户持有由所述下一个用户正在等待的资源；以及
管理在所述链中打头的所述用户，如同它的需求至少是所述链中最有需求的等待者的需求。
16.权利要求15的程序存储设备，其中所述管理步骤包括如下步骤：
把系统资源分配给所述链中打头的所述用户，如同它的需求至少是所述链中所述最有需求的等待者的需求。
17.一种机器可读的程序存储设备，其有形地体现可由该机器执行的指令程序，用于执行方法步骤以对在一信息管理系统中访问一个或多个资源的用户之间的资源争用进行管理，每个所述用户有被赋予的需求并且能够是它寻求访问的资源的持有者或等待者，所述方法步骤包括：
识别所述资源的一群集，其中，在该群集中的每个资源或者由等待该群集中另一资源的一个用户所持有，或者由持有该群集中另一资源的一个用户所等待；
确定对所述群集中任何资源最有需求的需求者的需求；
识别所述群集中一个资源的持有者，该持有者不在等待任何其他资源；以及
管理所述资源的所述持有者，如同它的需求至少是所述群集中任何资源的所述最有需求的等待者的需求。
18.权利要求17的程序存储设备，其中所述管理步骤包括如下步骤：
把系统资源分配给所述资源的所述持有者，如同它的需求至少是所述群集中任何资源的所述最有需求的等待者的需求。
19.权利要求17的程序存储设备，其中所述识别一个群集的步骤是对收到一个资源争用状态变化的通知作出响应而进行的，并包括如下步骤：
如果一个资源现在被等待一个群集中另一资源的一用户所持有或者现在被持有该群集中另一资源的一用户所等待，则把该资源新赋予该群集。
20.权利要求17的程序存储设备，其中所述识别一个群集的步骤是对收到一个资源争用状态变化的通知作出响应而进行的，并包括如下步骤：
如果一个资源不再被等待一个群集中另一资源的用户所持有或者不再被持有该群集中另一资源的用户所等待，则从该群集中去掉该资源。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/335,046 | 2002-12-31 | ||
| US10/335,046 US20040139142A1 (en) | 2002-12-31 | 2002-12-31 | Method and apparatus for managing resource contention |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1514366A true CN1514366A (zh) | 2004-07-21 |
| CN1256671C CN1256671C (zh) | 2006-05-17 |
Family
ID=32710898
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB2003101215958A Expired - Fee Related CN1256671C (zh) | 2002-12-31 | 2003-12-29 | 管理资源争用的方法和装置 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US20040139142A1 (zh) |
| JP (1) | JP3910577B2 (zh) |
| KR (1) | KR100586285B1 (zh) |
| CN (1) | CN1256671C (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101043419B (zh) * | 2006-03-24 | 2010-08-11 | 国际商业机器公司 | 用于域信息文件的更新同步的方法和请求者数据处理节点 |
| CN102346744A (zh) * | 2010-07-30 | 2012-02-08 | 国际商业机器公司 | 用于在多租户应用系统中处理物化表的装置 |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2558892A1 (en) * | 2004-03-13 | 2005-09-29 | Cluster Resources, Inc. | System and method for a self-optimizing reservation in time of compute resources |
| US20070061429A1 (en) * | 2005-09-12 | 2007-03-15 | Microsoft Corporation | Optimizing utilization of application resources |
| US8042122B2 (en) * | 2007-06-27 | 2011-10-18 | Microsoft Corporation | Hybrid resource manager |
| US8719300B2 (en) * | 2008-10-15 | 2014-05-06 | International Business Machines Corporation | Catalog performance plus |
| KR20110122361A (ko) * | 2010-05-04 | 2011-11-10 | 주식회사 팬택 | 무선통신시스템에서의 자원할당 방법 및 그 장치 |
| US8510739B2 (en) | 2010-09-16 | 2013-08-13 | International Business Machines Corporation | Shared request grouping in a computing system |
| US8918764B2 (en) * | 2011-09-21 | 2014-12-23 | International Business Machines Corporation | Selective trace facility |
| US9032484B2 (en) | 2011-10-31 | 2015-05-12 | International Business Machines Corporation | Access control in a hybrid environment |
| US9053141B2 (en) | 2011-10-31 | 2015-06-09 | International Business Machines Corporation | Serialization of access to data in multi-mainframe computing environments |
| US9274837B2 (en) * | 2013-05-17 | 2016-03-01 | International Business Machines Corporation | Assigning levels of pools of resources to a super process having sub-processes |
| US9722908B2 (en) | 2013-10-17 | 2017-08-01 | International Business Machines Corporation | Problem determination in a hybrid environment |
| CN105335237B (zh) * | 2015-11-09 | 2018-09-21 | 浪潮电子信息产业股份有限公司 | 一种操作系统的死锁预防方法 |
| US9858107B2 (en) | 2016-01-14 | 2018-01-02 | International Business Machines Corporation | Method and apparatus for resolving contention at the hypervisor level |
| US9965727B2 (en) | 2016-01-14 | 2018-05-08 | International Business Machines Corporation | Method and apparatus for resolving contention in a computer system |
| 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 |
| US10698785B2 (en) | 2017-05-30 | 2020-06-30 | International Business Machines Corporation | Task management based on an access workload |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4189771A (en) * | 1977-10-11 | 1980-02-19 | International Business Machines Corporation | Method and means for the detection of deadlock among waiting tasks in a multiprocessing, multiprogramming CPU environment |
| US5197130A (en) * | 1989-12-29 | 1993-03-23 | Supercomputer Systems Limited Partnership | Cluster architecture for a highly parallel scalar/vector multiprocessor system |
| US5202993A (en) * | 1991-02-27 | 1993-04-13 | Sun Microsystems, Inc. | Method and apparatus for cost-based heuristic instruction scheduling |
| 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 |
| EP0595453B1 (en) * | 1992-10-24 | 1998-11-11 | International Computers Limited | Distributed data processing system |
| 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 |
| 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 |
| US6442564B1 (en) * | 1999-06-14 | 2002-08-27 | International Business Machines Corporation | Facilitating workload management by using a location forwarding capability |
| US6721775B1 (en) * | 1999-08-12 | 2004-04-13 | International Business Machines Corporation | Resource contention analysis employing time-ordered entries in a blocking queue and waiting queue |
| US6681241B1 (en) * | 1999-08-12 | 2004-01-20 | International Business Machines Corporation | Resource contention monitoring employing time-ordered entries in a blocking queue and waiting queue |
| CA2302959A1 (en) * | 2000-03-23 | 2001-09-23 | Ibm Canada Limited-Ibm Canada Limitee | Priority resource allocation in programming environments |
| US20020083063A1 (en) * | 2000-12-26 | 2002-06-27 | Bull Hn Information Systems Inc. | Software and data processing system with priority queue dispatching |
-
2002
- 2002-12-31 US US10/335,046 patent/US20040139142A1/en not_active Abandoned
-
2003
- 2003-11-28 JP JP2003400703A patent/JP3910577B2/ja not_active Expired - Fee Related
- 2003-12-29 CN CNB2003101215958A patent/CN1256671C/zh not_active Expired - Fee Related
- 2003-12-30 KR KR1020030099765A patent/KR100586285B1/ko not_active IP Right Cessation
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101043419B (zh) * | 2006-03-24 | 2010-08-11 | 国际商业机器公司 | 用于域信息文件的更新同步的方法和请求者数据处理节点 |
| CN102346744A (zh) * | 2010-07-30 | 2012-02-08 | 国际商业机器公司 | 用于在多租户应用系统中处理物化表的装置 |
| US8533159B2 (en) | 2010-07-30 | 2013-09-10 | International Business Machines Corporation | Processing materialized tables in a multi-tenant application system |
| CN102346744B (zh) * | 2010-07-30 | 2013-11-13 | 国际商业机器公司 | 用于在多租户应用系统中处理物化表的装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20040139142A1 (en) | 2004-07-15 |
| KR100586285B1 (ko) | 2006-06-07 |
| CN1256671C (zh) | 2006-05-17 |
| JP2004213628A (ja) | 2004-07-29 |
| KR20040062407A (ko) | 2004-07-07 |
| JP3910577B2 (ja) | 2007-04-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1514366A (zh) | 管理资源争用的方法和装置 | |
| CN1711523A (zh) | 用于管理多系统群集中资源争用的方法和装置 | |
| CN1167020C (zh) | 数据共享方法和终端 | |
| CN1284095C (zh) | 多处理器系统中的任务分配方法和多处理器系统 | |
| CN1114859C (zh) | 数据共享方法和计算机体系结构 | |
| KR102072726B1 (ko) | 데이터베이스로의 미들-티어 트랜잭션 로그들의 인라인 위임을 지원하는 시스템들 및 방법들 | |
| CN1443323A (zh) | 控制集群计算环境的系统通信量的方法、系统和程序产品 | |
| CN1729442A (zh) | 在网络中使用共享资源的方法和装置 | |
| CN1906583A (zh) | 信息处理设备、中断处理控制方法、以及计算机程序 | |
| CN1993674A (zh) | 多芯架构中的资源管理 | |
| CN1777107A (zh) | 高性能计算(hpc)系统中的按需式例示 | |
| CN1222902C (zh) | 通信网中的方法和设备 | |
| CN1677979A (zh) | 通过网络在计算机之间共享对象的系统和方法 | |
| CN101039330A (zh) | 在移动应用程序环境中使用的产品 | |
| CN1719831A (zh) | 基于集群路由器结构的高可用分布式边界网关协议系统 | |
| CN101031886A (zh) | 网络系统、管理计算机、集群管理方法以及计算机程序 | |
| CN1298509A (zh) | 在分布式系统中租用委派证的方法、装置和产品 | |
| CN1581771A (zh) | 验证系统、服务器和验证方法及程序 | |
| CN1783086A (zh) | 用于在数据库管理系统中的查询管理的系统和方法 | |
| CN1612610A (zh) | 分布式发送媒体数据的体系结构 | |
| CN101043469A (zh) | 一种呈现信息的处理方法 | |
| CN107688489B (zh) | 一种调度任务的方法和系统 | |
| CN1823492A (zh) | 对等环境中的用户交互作用系统和方法 | |
| CN1926825A (zh) | 能够用帧来代替控制站的终端 | |
| CN1889045A (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 | ||
| C17 | Cessation of patent right | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20060517 Termination date: 20100129 |