用于并发性控制的技术的制作方法

本公开总体上涉及并行计算的领域。具体地，提出了一种用于系统中的事务的并发性控制的技术，所述系统包括访问数据库系统的多个应用实例。该技术可以以方法、计算机程序、装置和系统来体现。

背景技术：

在下一代(5g)移动通信网络中，存在围绕基于服务的架构(sba)范例构建网络架构的总体趋势，这意味着将存在诸如核心网络(cn)之类的网络域，在网络域中，功能组件被定义为“服务”，即自包含的功能，该“服务”可以以隔离的方式进行修改(而不影响其他服务)。服务将可能以无状态方式构建，即服务的应用逻辑和数据上下文将被分离，这意味着服务通常会将其上下文在外部存储在专有数据库中。尽管这种架构将实现各种云基础设施特征，如自动扩展或自动修复，但是服务的无状态性质也意味着相同或不同服务的多个实例可能需要同时访问同一数据，从而潜在地导致竞争状况(racecondition)。如果不能在这些访问之间提供适当的并发性控制，则后果可能是例如由于对已经由其他实例更新的数据的重写而导致的系统上的状态的不一致。一个示例是当进行需要改变用户设备(ue)的会话上下文的某些会话管理动作(例如，会话建立或会话修改)时，以及当针对影响相同用户路径的相同ue同时发生切换时。

图1中示出了竞争状况处理是必需的示例性情况，其中不同服务的实例访问ue会话上下文数据库中存储的属性。在该过程的步骤1中，服务a的实例从数据库中读取属性y，该属性y被成功地返回。然后，服务a的实例检查属性y的值，并且如果该属性具有某个值(y＝a)，则执行过程1，该过程1可以涉及其他服务和多个数据库访问(不仅读取，而且写入)。在步骤2中，另一服务b的实例可以同样地读取属性x并在属性x具有某个值(x＝m)时开始过程2，以使得然后同时进行这些过程。图中指示的步骤3、4a和5是过程1的一部分，其中属性x在步骤4a中被修改。概括地讲，例如，示出了另一服务实例(即，服务c的实例)修改属性x，但是这也可以是服务a的实例。此外，在步骤4b(可以与过程1同时执行)中，服务d的实例将属性y修改为与a不同的值。如上所述，由于值a是触发过程1(y＝a)所必需的，因此过程1可能无效，并且可能需要执行回滚(rallback)功能。然而，回滚并非总是可以的，尤其是在过程可能触发其他过程以使得要回滚的变化被链接在一起时。

用于处理这种情况的并发性控制的各种技术是众所周知的。一种这样的技术是严格锁定(也称为显式锁定)，其中采用显式锁来处理竞争状况。这样的技术的示例在图2中示出，其中，服务a的实例x被授权对ue上下文数据库c中存储的记录r的排他性访问(读取、写入或两者)，其中，其他服务实例(例如实例y(其可以是同一服务a的实例，或是需要访问同一记录r的另一服务b的实例))在尝试访问记录r时将被阻止，直到保持锁定的实例(即实例x)释放该锁定为止。

另一种技术是乐观锁定(optimisticlocking)(也称为机会并发性控制(occ))，该乐观锁定通常基于以下假设：多个事务可以频繁完成而不会互相干扰。使用occ，在运行时，事务可以使用数据资源而无需获取对那些资源的锁定。在提交之前，每个事务都验证没有其他事务修改过它已读取的数据，其中可能需要的是：针对同一数据集的读取操作在任何occ写入事务之前。如图3的示例所示，在一个变体中，数据库可以生成令牌(例如，其可以是记录r的最新更新的时间戳)并将令牌发送给读取记录r的实例，并且然后要求每个提交的事务在任何更新请求中发送该令牌。如果存在对记录r的后续写入，则令牌被更新(被无效)，并且因此，使用无效令牌更新记录r的所有其他尝试揭示冲突的修改，并且因此将失败。在这些情况下，提交的事务回滚并可以被重新开始。

尽管用于并发性控制的这些技术已在某些场景中证明其适合性，但这些技术在其他场景中可能遭遇其缺点。例如，严格锁定可能是长且昂贵的操作，尤其是当它用于复杂事务时。在诸如5g网络之类的移动通信网络中，涉及cn中的不同实体或服务之间的多个交互的过程通常需要来自不同实体的多个数据库访问(读取和写入两者)。如果所有所涉及的数据库更新成功，则这种事务成功。如果使用严格锁定，则更新实体必须在事务开始时发送对相关属性/记录的排他性锁定请求，并保持锁定，直到最后的数据库更新完成。然而，这意味着在更新终止之前，没有其他实体可以访问该数据，这在复杂过程的情况下可能花费很长时间。这还包括可能需要参与同一事务的同一服务的其他实例，这些实例由于排他性锁定而无法参与。作为解决方案，可能需要复杂的机制来将同一事务中的消息重定向到锁定数据库的实体。

另一方面，occ是一种更快的方法，并且可以适合于在不同事务之间的数据争用通常较低的移动通信网络中使用。然而，occ在具有多个数据库更新的复杂事务的情况下可能也是不合适的。例如，如果在事务期间数据库更新无效，则将必须回滚所有先前的且成功的数据库事务。该回滚的实现可能是复杂的，因为一方面推断更新服务实例应回滚的内容可能是麻烦的(可能涉及到若干实例，并且应回滚的内容通常取决于实例的功能逻辑)，另一方面，甚至可能已经基于先前的交互做出了一些判定，这些先前的交互被乐观地认为是成功的。与多步骤事务回滚相关的另一个问题是，occ可能导致不足的并发事务。当更新在一个事务中无效时(这发起回滚和重新开始)，这可能发生。在该回滚事件(其还可能涉及针对先前成功的事务的数据库更新)期间，仍在进行的另一个事务的步骤也可能得到更新无效并且也开始回滚。

当读取整个属性范围时，可能发生适用于严格锁定和occ两者的与数据库事务相关的附加问题。如果这些属性中的任一属性的值改变，则即使改变的值没有修改并行运行的其他过程的结果，通常也会触发影响进行的事务的竞争状况处理。在这种情况下，如果不触发竞争状况处理，则可能是有益的。

技术实现要素：

因此，需要一种避免上述问题中的一个或多个问题或其他问题的用于并发性控制的技术。

根据第一方面，提供了一种用于系统中的事务的并发性控制的方法，该系统包括访问数据库系统的多个应用实例。该方法由数据库系统执行，并且包括：从多个应用实例中的第一应用实例接收指示事务开始的事务开始请求，以在事务进行时针对不属于该事务的访问请求锁定数据库系统中存储的数据；在事务进行时从多个应用实例中的第二应用实例接收对数据中的至少一部分数据的访问请求；以及基于检查访问请求是否属于该事务，控制对访问请求的接受。

控制对访问请求的接受可以包括以下之一：当访问请求属于事务时，接受访问请求；以及当访问请求不属于事务时，拒绝访问请求。第一应用实例可以不同于第二应用实例。第一应用实例和第二应用实例可以是不同类型的应用的实例。事务开始请求可以包括唯一地标识事务的第一事务标识符，并且访问请求可以包括指示该访问请求所属于的事务的第二事务标识符，其中，检查访问请求是否属于该事务可以包括比较第一事务标识符与第二事务标识符。锁定数据可以包括利用第一事务标识符来标记数据，其中，在比较第一事务标识符与第二事务标识符之前，第一事务标识符可以基于数据中的要由访问请求访问的至少一部分数据的标记而被获取。

访问请求可以是写入请求，并且可以接受来自多个应用实例的对数据的读取请求，而与读取请求是否属于该事务无关。事务开始请求可以包括对要在事务进行时锁定的数据的指示。而且，要锁定的数据可以包括经受作为进行的事务的一部分而执行的读取请求的数据。事务开始请求可以对应于作为事务的一部分而执行的初始读取请求。要锁定的数据可以包括数据库系统的记录的一个或多个属性。记录的一个或多个属性可以对应于记录的多个属性中的属性子集，其中，属性子集包括如下属性：被标识为能够在进行的事务中经受竞争状况的属性。该方法还可以包括接收指示事务结束的事务结束请求。可以从多个应用实例中的第三应用实例接收事务结束请求，第三应用实例不同于第一应用实例。该系统可以是移动通信系统，并且数据库系统可以是在该移动通信系统中采用的中央数据库系统。

根据第二方面，提供了一种用于系统中的事务的并发性控制的方法，该系统包括访问数据库系统的多个应用实例。该方法由多个应用实例中的第一应用实例执行，并且包括：触发向数据库系统发送指示事务开始的事务开始请求，以使数据库系统在事务进行时针对不属于该事务的访问请求锁定数据库系统中存储的数据。

根据第二方面的方法从第一应用实例的角度定义了一种方法，该方法可以作为对根据第一方面的方法的补充。因此，第二方面的方法也可以包括针对第一方面的方法描述的适用于第二方面的方法的那些方面，反之亦然。

如在第一方面的方法中，事务开始请求可以包括唯一地标识事务的事务标识符。事务开始请求可以包括对要在事务进行时锁定的数据的指示。而且，事务开始请求可以对应于作为事务的一部分而执行的初始读取请求。要锁定的数据可以包括数据库系统的记录的一个或多个属性。记录的一个或多个属性可以对应于记录的多个属性中的属性子集，其中，属性子集包括如下属性：被标识为能够在进行的事务中经受竞争状况的属性。该方法还可以包括触发向第二应用实例发送包括事务标识符的消息，该事务标识符向第二应用实例指示该消息属于进行的事务。该方法还可以包括触发向数据库系统发送指示事务结束的事务结束请求。该系统可以是移动通信系统，并且数据库系统可以是在该移动通信系统中采用的中央数据库系统。

根据第三方面，提供了一种用于系统中的事务的并发性控制的方法，该系统包括访问数据库系统的多个应用实例。该方法由多个应用实例中的第二应用实例执行，并且包括：触发向数据库系统发送对数据库系统中存储的数据中的至少一部分数据的访问请求，针对不属于进行的事务的访问请求，该数据由数据库系统锁定。

根据第三方面的方法从第二应用实例的角度定义了一种方法，该方法可以作为对根据第一方面的方法或根据第二方面的方法的补充。因此，第三方面的方法也可以包括针对第一方面和第二方面的方法描述的适用于第三方面的方法的那些方面，反之亦然。

根据第一方面的方法，该方法可以包括以下之一：当访问请求属于进行的事务时，从数据库系统接收对访问请求的接受；以及当访问请求不属于进行的事务时，从数据库系统接收对访问请求的拒绝。该方法还可以包括：从第一应用实例接收消息，该消息包括指示该消息属于进行的事务的事务标识符。访问请求可以包括指示访问请求所属于的事务的事务标识符。该方法还可以包括触发向数据库系统发送指示事务结束的事务结束请求。该系统可以是移动通信系统，并且数据库系统可以是在该移动通信系统中采用的中央数据库系统。

根据第四方面，提供了一种计算机程序产品。该计算机程序产品包括程序代码部分，该程序代码部分用于当在一个或多个计算设备(例如，处理器或处理器的分布式集合)上执行计算机程序产品时执行第一、第二和第三方面中的至少一个方面的方法。计算机程序产品可以被存储在计算机可读记录介质(例如，半导体存储器、dvd、cd-rom等)上。

根据第五方面，提供了一种计算单元，该计算单元被配置为执行用于系统中的事务的并发性控制的数据库系统，该系统包括访问数据库系统的多个应用实例。该计算单元包括至少一个处理器和至少一个存储器，该至少一个存储器包含可由至少一个处理器执行的指令，使得数据库系统可操作用于执行本文针对第一方面提出的方法步骤中的任何方法步骤。

根据第六方面，提供了一种计算单元，该计算单元被配置为执行用于系统中的事务的并发性控制的第一应用实例，该系统包括访问数据库系统的多个应用实例。该计算单元包括至少一个处理器和至少一个存储器，该至少一个存储器包含可由至少一个处理器执行的指令，使得第一应用实例可操作用于执行本文针对第二方面提出的方法步骤中的任何方法步骤。

根据第七方面，提供了一种计算单元，该计算单元被配置为执行用于系统中的事务的并发性控制的第二应用实例，该系统包括访问数据库系统的多个应用实例。该计算单元包括至少一个处理器和至少一个存储器，该至少一个存储器包含可由至少一个处理器执行的指令，使得第二应用实例可操作用于执行本文针对第三方面提出的方法步骤中的任何方法步骤。

根据第八方面，提供了一种系统，该系统包括第五方面的计算单元、第六方面的计算单元和第七方面的计算单元。

附图说明

在下文中参考附图描述本文中提出的技术的实施方式，在附图中：

图1示出了需要并发性控制的示例性过程的信令图；

图2示出了例示严格锁定的使用的信令图；

图3是例示occ的使用的信令图；

图4a至图4c示出了根据本公开的被配置为执行数据库系统的计算单元、被配置为执行第一应用实例的计算单元、以及被配置为执行第二应用实例的计算单元的示例性组成；

图5示出了根据本公开的可以由数据库系统执行的方法；

图6示出了根据本公开的可以由第一应用实例执行的方法；

图7示出了根据本公开的可以由第二应用实例执行的方法；

图8示出了根据本公开的数据库系统、第一应用实例和第二应用实例之间的示例性交互的信令图；

图9示出了根据本公开的示例性竞争状况检查方法的流程图；以及

图10示出了数据库系统与若干服务实例之间的示例性交互的信令图，该信令图基于图1的示例并且在其中采用本公开的技术。

具体实施方式

在下面的描述中，出于解释而非限制的目的，阐述了具体细节，以便提供对本公开的全面理解。然而，对本领域技术人员将显而易见的是：本公开可在脱离这些具体细节的其它实施例中实行。

本领域技术人员还将意识到：可以使用单独的硬件电路、使用与编程的微处理器或通用计算机相结合的软件功能、使用一个或多个专用集成电路(asic)和/或使用一个或多个数字信号处理器(dsp)来实现在下文中解释的步骤、服务和功能。还将了解：当根据方法描述本公开时，本公开也可以以一个或多个处理器和耦接到该一个或多个处理器的一个或多个存储器来体现，其中，该一个或多个存储器被编码有一个或多个程序，该一个或多个程序在由一个或多个处理器执行时执行本文公开的步骤、服务和功能。

图4a示意性地示出了计算单元400的示例性组成，该计算单元400被配置为执行用于系统中的事务的并发性控制的数据库系统，该系统包括访问数据库系统的多个应用实例。计算单元400包括至少一个处理器402和至少一个存储器404，其中，至少一个存储器404包含可由至少一个处理器402执行的指令，使得数据库系统可操作用于执行本文在下面参考数据库系统描述的方法步骤。

图4b示意性地示出了计算单元410的示例性组成，该计算单元410被配置为执行用于系统中的事务的并发性控制的第一应用实例，该系统包括访问数据库系统的多个应用实例。计算单元410包括至少一个处理器412和至少一个存储器414，其中，至少一个存储器414包含可由至少一个处理器412执行的指令，使得第一应用实例可操作用于执行本文在下面参考第一应用实例描述的方法步骤。

图4c示意性地示出了计算单元420的示例性组成，该计算单元420被配置为执行用于系统中的事务的并发性控制的第二应用实例，该系统包括访问数据库系统的多个应用实例。计算单元420包括至少一个处理器422和至少一个存储器424，其中，至少一个存储器424包含可由至少一个处理器422执行的指令，使得第二应用实例可操作用于执行本文在下面参考第二应用实例描述的方法步骤。

将理解的是：例如，计算单元400、计算单元410和计算单元420中的每一个可以在物理计算单元或虚拟化计算单元(例如虚拟机)上实现。还将理解的是：计算单元400、计算单元410和计算单元420中的每一个可以不必在独立的计算单元上实现，而是也可以被实现为以软件和/或硬件实现的组件，该组件驻留在多个分布式计算单元上(例如在云计算环境中)。

图5示出了根据本公开的可以由在计算单元400上执行的数据库系统执行的方法。该方法专用于执行系统中的事务的并行性控制，该系统包括访问数据库系统的多个应用实例。在步骤s502中，数据库系统可以从多个应用实例中的第一应用实例(例如，在计算单元410上执行的第一应用实例)接收指示事务开始的事务开始请求，以在事务进行时针对不属于该事务的访问请求锁定数据库系统中存储的数据。在步骤s504中，数据库系统可以在事务进行时从多个应用实例中的第二应用实例(例如，在计算单元420上执行的第二应用实例)接收对数据中的至少一部分数据的访问请求。在步骤s506中，数据库系统可以基于检查访问请求是否属于该事务来控制对访问请求的接受。在步骤s508中，数据库系统可以接收指示事务结束的事务结束请求。

访问数据库系统的多个应用实例可以包括一个或多个应用的实例。多个应用实例可以同时访问数据库系统，使得可以使用事务来处理在访问数据库系统时发生的竞争状况。例如，数据库系统可以对应于数据库管理系统(dbms)，但是不限于此，并且将理解的是：数据库系统通常可以对应于在数据库上部的层上执行的任何其他应用逻辑。每个事务可以包括对数据库系统的一个或多个访问请求(例如，读取和/或写入请求)，其中一个或多个访问请求中的每一个都可以由多个应用实例之一执行。事务的访问请求可以不必源自同一应用实例，而是一个或多个访问请求可以包括来自多个应用实例中的不同应用实例(甚至可能来自不同类型的应用的实例)的访问请求。如果一个或多个访问请求中的所有访问请求本身都是成功的(例如，没有发生由竞争状况引起的副作用(sideeffect))，则事务可以被认为是成功的。

根据步骤s502，可以通过事务开始请求来发起事务，该事务开始请求指示事务开始并且使数据库系统在事务进行时针对不属于该事务的访问请求锁定数据库系统中存储的数据。因此，不是由从其接收事务开始请求的第一应用实例专有地锁定数据，而是可以基于事务本身来锁定数据，使得可以基于根据步骤s506检查访问请求是否属于进行的事务，来控制对数据中的至少一部分数据的访问请求(其是根据步骤s504接收的)的接受。以这种方式，可以由数据库系统本身来管理对数据的锁定和对数据的访问的授权，以使得锁定可以是事务专有的，而不是请求进行锁定的应用实例专有的(例如，在上述严格锁定技术中是这种情况)。

基于检查访问请求是否属于事务的结果，可以接受或拒绝该访问请求。因此，控制对访问请求的接受可以包括以下之一：当访问请求属于事务时，接受访问请求；以及当访问请求不属于事务时，拒绝访问请求。由于对数据的锁定不是特定应用实例专有的，因此从其接收事务开始请求的第一应用实例可以与从其接收访问请求的第二应用实例不同。第一应用实例和第二应用实例甚至可以是不同类型的应用的实例。

为了标识访问请求是否属于进行的事务，可以向该事务分配事务标识符，并且访问请求可以包括事务标识符，可以检查该事务标识符与进行的事务的事务标识符的匹配。在一个变体中，事务开始请求因此可以包括唯一地标识事务的第一事务标识符，并且访问请求可以包括指示该访问请求所属于的事务的第二事务标识符，其中，检查访问请求是否属于该事务可以包括比较第一事务标识符和第二事务标识符。在第一事务标识符和第二事务标识符匹配时，访问请求可以被接受，否则被拒绝。

数据库系统可以在接收到事务开始请求时存储第一事务标识符，以稍后用于与后续访问请求中包括的事务标识符进行比较。在一个实施方式中，可以与要锁定的数据相关联地存储第一事务标识符，使得当访问请求尝试访问该数据中的至少一部分数据时，可以检查访问请求中包括的事务标识符是否与和数据相关联地存储的第一事务标识符匹配。换句话说，锁定数据可以包括利用第一事务标识符来标记数据，其中，在比较第一事务标识符与第二事务标识符之前，第一事务标识符可以基于数据中的要由访问请求访问的至少一部分数据的标记而被获取。

访问请求可以对应于读取请求或写入请求。由于在发生竞争状况时，通常只有写入请求可能引起数据中的不一致，因此锁定可以仅应用于写入请求。因此，从第二应用实例接收的访问请求可以是写入请求，其中，可以接受来自多个应用实例的对数据的读取请求，而与读取请求是否属于事务无关。

可以以不同的方式指定要锁定的数据。在一个变体中，可以在发送事务开始请求时在第一应用实例的请求上指定要锁定的数据，例如，事务开始请求可以包括对要在事务进行时锁定的数据的指示。在可以替代前一变体或附加于前一变体的另一变体中，可以在每次作为进行的事务的一部分而执行数据库访问时标记要锁定的数据，例如，要锁定的数据可以包括经受作为进行的事务的一部分而执行的读取请求的数据。在一个特定的这种变体中，第一读取请求可以由事务开始请求本身给出，即，事务开始请求可以对应于作为事务的一部分而执行的初始读取请求。要锁定的数据可以包括一个或多个记录，并且在一个特定变体中，要锁定的数据可以包括数据库系统的记录的一个或多个属性。在这种变体中，可以仅将要由访问请求访问的、可能经受潜在竞争状况的特定属性标记为要锁定的。因此，记录的一个或多个属性可以对应于记录的多个属性中的属性子集，其中，属性子集包括如下属性：被标识为可以在进行的事务中经受竞争状况的属性。以这种方式，控制可以被限制到属性的最小集合，这是有利的，因为在数据库访问中通常可以一次更新许多属性，但是仅需要针对与其他事务的潜在竞争状况控制几个属性。例如，可以从发送事务开始请求的第一应用实例的应用逻辑中标识可能在进行的事务中经受竞争状况的属性。

当要释放对数据的锁定时，根据步骤s508，数据库系统可以接收指示事务结束的事务结束请求。在接收到事务结束请求时，数据库系统可以释放对数据的锁定。可以从发送事务开始请求的第一应用实例和发送访问请求的第二应用实例中的一个接收事务结束请求。如上所述，由于对数据的锁定可以不是特定应用实例专有的，因此事务结束请求也可以从多个应用实例中的第三应用实例接收，其中，第三应用实例可以不同于第一应用实例(以及不同于第二个应用实例)。

包括多个应用实例和数据库系统的系统可以是移动通信系统，并且数据库系统可以是在移动通信系统中采用的中央数据库系统。例如，移动通信系统可以包括诸如5g网络之类的蜂窝网络，并且数据库系统可以是例如存储针对向移动通信系统注册的ue的会话上下文信息的数据库系统。应用实例可以对应于例如在移动通信系统的网络域中提供的、根据sba范例的服务的实例。

图6示出了根据本公开的可以由在计算单元410上执行的第一应用实例执行的方法。该方法专用于执行包括访问数据库系统(例如，在计算单元400上执行的数据库系统)的多个应用实例的系统中的事务的并发性控制。第一应用实例的操作可以作为对以上关于图5描述的数据库系统的操作的补充，并且因此，以上关于第一应用实例的操作描述的各方面也可以适用于在下文中描述的在计算单元410上执行的第一应用实例的操作。因此，在下文中将省略不必要的重复。

在步骤s602中，第一应用实例可以触发向数据库系统发送指示事务开始的事务开始请求，以使数据库系统在事务进行时针对不属于该事务的访问请求锁定数据库系统中存储的数据。在步骤s604中，第一应用实例可以触发向数据库系统发送指示事务结束的事务结束请求。

如以上关于图5所描述的，事务开始请求可以包括唯一地标识事务的事务标识符。事务开始请求可以包括对要在事务进行时锁定的数据的指示。而且，事务开始请求可以对应于作为事务的一部分而执行的初始读取请求。要锁定的数据可以包括数据库系统的记录的一个或多个属性。记录的一个或多个属性可以对应于记录的多个属性中的属性子集，其中，属性子集包括如下属性：被标识为可以在进行的事务中经受竞争状况的属性。第一应用实例还可以触发向第二应用实例发送包括事务标识符的消息，该事务标识符向第二应用实例指示该消息属于进行的事务。通过在发送给第二应用实例的消息中包括事务标识符，第二应用实例可以知道该消息属于进行的事务，并且因此第二应用实例进而可以将事务标识符包括在自身发送的其他消息中，从而将事务性信息传达给其他应用实例，产生经受相同的事务的消息流。该系统可以是移动通信系统，并且数据库系统可以是在该移动通信系统中采用的中央数据库系统。

图7示出了根据本公开的可以由在计算单元420上执行的第二应用实例执行的方法。该方法专用于执行包括访问数据库系统(例如，在计算单元400上执行的数据库系统)的多个应用实例的系统中的事务的并发性控制。第二应用实例的操作可以作为对以上关于图5描述的数据库系统的操作和/或以上关于图6描述的第一应用实例的操作的补充，并且因此，以上关于关于第二应用实例的操作的各方面也可以适用于在下文中描述的第二应用实例的操作。因此，在下文中将省略不必要的重复。

在步骤s702中，第二应用实例可以触发向数据库系统发送对数据库系统中存储的数据中的至少一部分数据的访问请求，针对不属于进行的事务的访问请求，该数据由数据库系统锁定。在步骤s704中，第二应用实例可以在访问请求属于进行的事务时从数据库系统接收对访问请求的接受，或者在访问请求不属于进行的事务时从数据库系统接收对访问请求的拒绝。在步骤s706中，第二应用实例可以触发向数据库系统发送指示事务结束的事务结束请求。

如以上关于图5和图6所描述的，访问请求可以包括指示访问请求所属于的事务的事务标识符。第二应用实例还可以从第一应用实例接收包括事务标识符的消息，该事务标识符指示该消息属于进行的事务。访问请求中包括的事务标识符可以对应于在来自第一应用实例的消息中接收的事务标识符，使得事务标识符可以对应于沿着经受进行的事务的消息流发送的事务性信息。当访问请求中包括的事务标识符对应于不同的事务标识符时，访问请求可以属于与进行的事务不同的事务。该系统可以是移动通信系统，并且数据库系统可以是在该移动通信系统中采用的中央数据库系统。

图8示出了根据本公开的数据库系统、第一应用实例和第二应用实例之间的示例性交互的信令图。在图8的示例中，数据库系统由附图标记802表示，并且对应于移动通信系统的ue会话上下文数据库，第一应用实例由附图标记804表示，并且对应于在移动通信系统中提供的服务a的实例x，第二应用实例由附图标记806表示，并且对应于在移动通信系统中提供的服务a(或另一服务b)的实例y。

在该过程的步骤1中，第一应用实例804可以向数据库系统802发送事务开始请求，该事务开始请求包括第一事务标识符id1和对要锁定的数据的指示，要锁定的数据在所示示例中是属性列表(属性1、2、3)。如图所示，事务开始请求可以以读取请求的形式出现，例如用于读取所请求的属性的值。在接收到事务开始请求时，数据库系统802可以与第一事务标识符id1相关联地保存所请求的属性，并发回确认，以及将所请求的属性值返回给第一应用实例804。要注意的是，针对所请求的属性的锁定可以不是第一应用实例804专有的，而是标识符id1所标识的第一事务专有的。如果在事务开始请求中未指定属性列表，则要锁定的数据可以包括经受作为具有标识符id1的第一事务的一部分而执行的后续读取请求的数据。

在步骤2中，第二应用实例806可以类似地向数据库系统802发送事务开始请求，该事务开始请求包括第二事务标识符id2和对要锁定的数据的指示，在所示示例中，该要锁定的数据是属性1、4和5的列表。事务开始请求可以同样以读取请求的形式出现，例如，用于读取所请求的属性1、4和5的值。在接收到事务开始请求时，数据库系统802可以与第二事务标识符id2相关联地保存所请求的属性，并发回确认，以及将所请求的属性值返回给第二应用实例806。要注意的是，经受具有标识符id1的第一事务的属性1、2和3的列表与经受具有标识符id2的第二事务的属性1、4和5的列表重叠，但是这在该阶段不触发任何具体操作。

在步骤3中，第二应用实例806可以向数据库系统802发送针对特定属性(即，在所示示例中为属性2)的写入请求，其中，该写入请求包括第二事务标识符id2，该第二事务标识符id2指示该写入请求属于具有标识符id2的第二事务。然后，数据库系统802可以通过比较第一事务标识符id1和第二事务标识符id2来执行竞争状况(rc)检查，并且由于标识符的不匹配，数据库系统802可以检测到存在用于写入被另一事务(即，具有标识符id1的第一事务)锁定的属性(2)的尝试。数据库系统802因此可以通过在步骤4中向第二应用实例806发送失败指示来拒绝写入请求。

在完成具有标识符id1的第一事务内的所有数据库更新之后，在步骤5中，第一应用实例804可以向数据库系统802发送事务结束请求，该事务结束请求指示具有标识符id1的第一事务结束。在所示示例中，事务结束请求可以同样以读取请求的形式出现。在接收到事务结束请求时，数据库系统802可以移除针对具有标识符id1的第一笔事务的属性列表，并相应地停止事务。由于针对具有标识符id2的第二事务不再存在重叠的锁定属性，因此作为具有标识符id2的第二事务的一部分而执行的任何其他写入请求现在将成功，如图中的步骤6中示例性所示。这样的请求可以例如在上一次不成功的请求尝试之后(例如，在步骤3中的尝试)由第二应用实例806处启动的定时器来触发，或者在步骤5之后由来自数据库系统802的直接回叫来触发。

在该示例中，将理解的是：在步骤1和5之间，在第一应用实例804和第二应用实例806以及可能其他应用实例之间可以发生其他交互(为简单起见，未在图8中示出)。而且，将理解的是：事务结束请求不一定必须从第一应用实例804发送，而是也可以从在具有标识符id1的第一事务中涉及的另一个应用实例(可能属于与服务a和b不同的服务)发送。

图9示出了可以由数据库系统802执行的示例性竞争状况检查方法的流程图。本质上，该方法可以包括：对于针对具有标识符idx的事务而接收的访问请求(在所示示例中是写入请求)，将事务标识符idx与和要访问的数据相关联地存储的事务标识符进行比较。更具体地，如果要访问的数据对应于一个或多个属性，则可以检查是否针对其他事务存储了属性，并且如果是，则可以检查是否存在与这些属性的重叠。如果存在重叠，则可以拒绝访问请求。否则，如果不存在针对事务的属性，或者如果属性之间不存在重叠，则可以接受访问请求。作为这两种判定过程的示例性实施方式，可以想到的是，在接收到要控制的属性列表时，数据库系统802利用对应的事务标识符一起对所请求的属性应用标记。然后，当访问请求到达时，数据库系统802可以检查这些标记，并且，如果存在具有不同事务标识符的标记，则可以拒绝访问请求。

图10示出了数据库系统与若干服务实例之间的示例性交互的信令图，该信令图基于以上关于图1描述的示例并且为其提供并发性控制。因此，图10的信令图基本上等同于图1的信令图，并且因此在下文中将仅描述不同之处。

在该过程的步骤1中，服务a的实例开始新事务，并将读取请求标记为包括事务id的事务开始请求。该实例还可以标记可以经受竞争状况的数据，即，如果在事务期间被修改则将使事务无效的数据。在所示示例中，属性y被标记。这里值得一提的是，在实践中，对数据库的更新操作可以包括多个属性(例如，在轻量目录访问协议(ldap)中，可以对可能持有甚至数百个属性的条目执行更新)，但并非所有属性都可以在改变时使事务无效。因此可以有利的是，仅标记潜在经受竞争状况的各个属性。这通常可以从执行更新的服务/应用的应用逻辑中得知。

在步骤3中，服务a的实例利用事务id标记所发送的消息(nservc操作请求)，以便将该消息指定为属于进行的事务。当服务c的实例接收到该消息时，它可以知道它需要将事务id包括在对ue会话上下文数据库的访问请求中，该访问请求作为事务的一部分而执行。因此，在步骤4a中，服务c的实例将事务id包括在针对属性x的写入请求中，该属性x因此将被数据库保存为要在进行的事务下锁定的属性。在步骤4b中，当接收到针对属性y的写入请求(用于将属性y更新为与a不同的值)时，数据库可以意识到锁定属性(在步骤1中属性y已被锁定)将要被修改，同时事务仍在进行中，因此数据库通过在步骤6中发送失败指示来拒绝该请求。在步骤7中，服务a的实例可以向数据库关闭事务，该数据库进而可以释放对在该事务下的属性的控制。

从上面已经显而易见的是，本公开提供了一种用于包括访问数据库系统的多个应用实例的系统中的事务的并发性控制的技术。根据所提出的技术，数据库系统可以控制对竞争状况的处理，而不是访问数据库的应用实例控制对竞争状况的处理，因此可以避免在整个事务完成期间由单个应用实例专有地阻塞数据的情形。所提出的竞争状况处理的结果可以是：可以有效地保护诸如属性列表之类的数据，直到事务完成。由于所提出的技术可以不允许对这种数据的修改，因此可以不需要回滚机制。此外，所提出的技术可以通过仔细选择可能经受竞争状况的那些属性来允许选择要控制的属性的最小集合，其中，该选择可以不仅限于由给定事务修改的那些属性。

本文提出的技术通常可以提供一种快速和简单的竞争状况处理方法，该方法可以尤其适用于发生复杂的多步骤事务并且数据争用通常较低的环境，例如在5g核心网络。由于本文提出的技术可以对执行数据库更新的服务的应用逻辑施加有限的设计约束，因此该技术可以形成多供应商环境中的标准解决方案的候选。可以不要求应用实例本身应对竞争状况处理，因为该逻辑实质上可以设置在数据库中。因此，通常可以通过实质上利用数据库功能使事务序列化来避免回滚功能。除了写入访问请求之外，在进行的事务的执行期间，始终可以针对并发性事务授权对所涉及数据的读取访问请求。

此外，进行的事务中内的请求通常可以由可以访问相同数据的(相同或不同服务的)不同实例来执行，唯一的要求是可能需要将事务标识符包括在访问请求中。因此，锁定可以不是应用实例专有的，而是事务本身专有的。换句话说，共享相同数据的每个其他应用实例都可以执行写入，前提是它属于同一事务。相同服务类型的实例的集合或池中的任何服务实例都可以在竞争状况的相对容易的管理下访问数据库。例如，这甚至可以简化诸如系统中的路由和负载平衡之类的方面。

相信根据前面的描述将完全理解本文呈现的技术的优点，并且将明显的是：在不脱离本发明的范围或不牺牲其所有有利效果的情况下，可以对其示例性方面的形式、结构和布置进行各种改变。因为可以通过很多方式来改变本文提出的技术，将意识到：本发明应该仅由所附权利要求的范围来限定。