Techniques for concurrency control

Abstract

A technology for concurrency control of transactions in a system is provided, the system comprising multiple application instances accessing a database system. The method of the technology is implemented by the database system and comprises: receiving (S502) a transaction start request indicating the start of a transaction from a first application instance among the multiple application instances, so as to lock data stored in the database system for access requests that do not belong to the transaction while the transaction is in progress; receiving (S504) an access request for at least a portion of the data from a second application instance among the multiple application instances while the transaction is in progress; and controlling (S506) acceptance of the access request based on checking whether the access request belongs to the transaction.

Description

Technical Field

[0001] The present disclosure generally relates to the field of parallel computing. Specifically, a technique for controlling the concurrency of transactions in a system including multiple application instances accessing a database system is proposed. The technique can be embodied in a method, a computer program, an apparatus, and a system. Background Art

[0002] In the next generation (5G) mobile communication networks, there is a general trend to build network architectures around the service-based architecture (SBA) paradigm, which means that there will be network domains such as the core network (CN) in which functional components are defined as "services", i.e., self-contained functions that can be modified in an isolated manner (without affecting other services). Services will likely be built in a stateless manner, i.e., the application logic and data context of the service will be separated, which means that the service will typically store its context externally in a proprietary database. Although this architecture will enable various cloud infrastructure features such as automatic expansion or automatic repair, the stateless nature of the service also means that multiple instances of the same or different services may need to access the same data at the same time, potentially leading to race conditions. If appropriate concurrency control is not provided between these accesses, the consequence may be, for example, inconsistency of state on the system due to the rewriting of data that has been updated by other instances. An example is when certain session management actions (e.g., session establishment or session modification) that require changes to the session context of the user equipment (UE) are performed, and when handovers occur simultaneously for the same UE that affect the same user path.

[0003] Figure 1An exemplary case in which race condition handling is necessary is shown in FIG, where instances of different services access attributes stored in a UE session context database. In step 1 of the process, an instance of service A reads attribute Y from the database, which is successfully returned. The instance of service A then checks the value of attribute Y and, if the attribute has a certain value (Y=A), performs process 1, which may involve other services and multiple database accesses (not only reading, but also writing). In step 2, an instance of another service B may similarly read attribute X and start process 2 when attribute X has a certain value (X=M), so that these processes are then performed simultaneously. Steps 3, 4a and 5 indicated in the figure are part of process 1, where attribute X is modified in step 4a. In summary, for example, another service instance (i.e., an instance of service C) is shown to modify attribute X, but this can also be an instance of service A. In addition, in step 4b (which can be performed simultaneously with process 1), an instance of service D modifies attribute Y to a value different from A. As described above, since value A is required to trigger process 1 (Y=A), process 1 may be invalid and a rollback function may need to be performed. However, rollback is not always possible, especially when processes may trigger other processes such that the changes to be rolled back are chained together.

[0004] Various techniques for concurrency control to handle this situation are well known. One such technique is strict locking (also called explicit locking), in which explicit locks are employed to handle race conditions. Examples of such techniques are described in Figure 2 , where an instance X of service A is granted exclusive access (read, write, or both) to a record R stored in a UE context database C, where other service instances (e.g., instance Y (which may be an instance of the same service A, or an instance of another service B that needs access to the same record R)) will be blocked when attempting to access the record R until the instance holding the lock (i.e., instance X) releases the lock.

[0005] Another technique is optimistic locking (also called opportunistic concurrency control (OCC)), which is generally based on the assumption that multiple transactions can complete frequently without interfering with each other. With OCC, transactions can use data resources without acquiring locks on those resources while they are running. Before committing, each transaction verifies that no other transaction has modified the data it has read, which may require that read operations on the same data set precede any OCC write transactions. Figure 3As shown in the example of , in one variation, the database can generate a token (e.g., which can be the timestamp of the most recent update to record R) and send the token to instances that read record R, and then require each committed transaction to send the token in any update request. If there is a subsequent write to record R, the token is updated (invalidated), and therefore, all other attempts to update record R using the invalid token reveal conflicting modifications and therefore will fail. In these cases, the committed transaction is rolled back and can be restarted.

[0006] Although these techniques for concurrency control have proven their suitability in certain scenarios, they may encounter their shortcomings in other scenarios. For example, strict locking can be a long and expensive operation, especially when it is used for complex transactions. In mobile communication networks such as 5G networks, processes involving multiple interactions between different entities or services in the CN typically require multiple database accesses (both read and write) from different entities. Such a transaction is successful if all the database updates involved are successful. If strict locking is used, the updating entity must send an exclusive lock request for the relevant attributes / records at the beginning of the transaction and keep the lock until the last database update is completed. However, this means that no other entity can access the data until the update is terminated, which may take a long time in the case of complex processes. This also includes other instances of the same service that may need to participate in the same transaction, which cannot participate due to exclusive locking. As a solution, complex mechanisms may be required to redirect messages in the same transaction to the entity that locked the database.

[0007] On the other hand, OCC is a faster method and may be suitable for use in mobile communication networks where data contention between different transactions is generally low. However, OCC may also be inappropriate in the case of complex transactions with multiple database updates. For example, if a database update is invalid during a transaction, all previous and successful database transactions will have to be rolled back. The implementation of this rollback may be complex because on the one hand it may be troublesome to infer what the update service instance should roll back (several instances may be involved, and what should be rolled back usually depends on the functional logic of the instance), and on the other hand, some decisions may even have been made based on previous interactions, which were optimistically considered to be successful. Another problem associated with multi-step transaction rollback is that OCC may result in insufficient concurrent transactions. This may occur when an update is invalid in one transaction (which initiates a rollback and restart). During this rollback event (which may also involve database updates for previously successful transactions), the steps of another transaction that is still in progress may also be invalidated and also begin to roll back.

[0008] Additional issues related to database transactions that apply to both strict locking and OCC may occur when reading the entire range of attributes. If the value of any of these attributes changes, race condition handling that affects the transaction in progress is usually triggered, even if the changed value does not modify the results of other processes running in parallel. In this case, it may be beneficial if race condition handling is not triggered. Summary of the invention

[0009] Therefore, there is a need for a technique for concurrency control that avoids one or more of the above problems or other problems.

[0010] According to a first aspect, a method for concurrency control of transactions in a system is provided, the system comprising multiple application instances accessing a database system. The method is performed by the database system and comprises: receiving a transaction start request indicating the start of a transaction from a first application instance among the multiple application instances, so as to lock data stored in the database system for access requests that do not belong to the transaction while the transaction is in progress; receiving an access request for at least a portion of the data from a second application instance among the multiple application instances while the transaction is in progress; and controlling acceptance of the access request based on checking whether the access request belongs to the transaction.

[0011] Controlling acceptance of an access request may include one of: accepting the access request when the access request belongs to a transaction; and rejecting the access request when the access request does not belong to a transaction. The first application instance may be different from the second application instance. The first application instance and the second application instance may be instances of different types of applications. The transaction start request may include a first transaction identifier that uniquely identifies a transaction, and the access request may include a second transaction identifier that indicates the transaction to which the access request belongs, wherein checking whether the access request belongs to the transaction may include comparing the first transaction identifier with the second transaction identifier. Locking data may include marking the data with the first transaction identifier, wherein before comparing the first transaction identifier with the second transaction identifier, the first transaction identifier may be obtained based on a marking of at least a portion of the data to be accessed by the access request in the data.

[0012] The access request may be a write request, and read requests for data from multiple application instances may be accepted regardless of whether the read request belongs to the transaction. The transaction start request may include an indication of data to be locked while the transaction is in progress. Moreover, the data to be locked may include data subject to a read request executed as part of the ongoing transaction. The transaction start request may correspond to an initial read request executed as part of the transaction. The data to be locked may include one or more attributes of a record of a database system. The one or more attributes of the record may correspond to a subset of attributes in a plurality of attributes of the record, wherein the subset of attributes includes the following attributes: attributes identified as being able to withstand a competition condition in the ongoing transaction. The method may also include receiving a transaction end request indicating the end of the transaction. The transaction end request may be received from a third application instance in the plurality of application instances, the third application instance being different from the first application instance. The system may be a mobile communication system, and the database system may be a central database system employed in the mobile communication system.

[0013] According to a second aspect, a method for concurrency control of transactions in a system is provided, the system comprising multiple application instances accessing a database system. The method is performed by a first application instance among the multiple application instances, and comprises: triggering sending a transaction start request indicating the start of a transaction to the database system, so that the database system locks data stored in the database system for access requests that do not belong to the transaction while the transaction is in progress.

[0014] The method according to the second aspect defines a method from the perspective of the first application example, which can be used as a supplement to the method according to the first aspect. Therefore, the method according to the second aspect can also include those aspects described for the method according to the first aspect that are applicable to the method according to the second aspect, and vice versa.

[0015] As in the method of the first aspect, the transaction start request may include a transaction identifier that uniquely identifies the transaction. The transaction start request may include an indication of data to be locked while the transaction is in progress. Moreover, the transaction start request may correspond to an initial read request executed as part of the transaction. The data to be locked may include one or more attributes of a record of a database system. The one or more attributes of the record may correspond to a subset of attributes among a plurality of attributes of the record, wherein the subset of attributes includes the following attributes: attributes identified as being able to withstand a competition condition in an ongoing transaction. The method may also include triggering the sending of a message including a transaction identifier to a second application instance, the transaction identifier indicating to the second application instance that the message belongs to an ongoing transaction. The method may also include triggering the sending of a transaction end request to a database system indicating the end of the transaction. The system may be a mobile communication system, and the database system may be a central database system employed in the mobile communication system.

[0016] According to a third aspect, a method for concurrency control of transactions in a system is provided, the system comprising multiple application instances accessing a database system. The method is performed by a second application instance in the multiple application instances, and comprises: triggering sending an access request to the database system for at least a portion of data stored in the database system, wherein for access requests that do not belong to the ongoing transaction, the data is locked by the database system.

[0017] The method according to the third aspect defines a method from the perspective of the second application example, and the method can be used as a supplement to the method according to the first aspect or the method according to the second aspect. Therefore, the method of the third aspect can also include those aspects of the method described for the first and second aspects that are applicable to the method of the third aspect, and vice versa.

[0018] According to the method of the first aspect, the method may include one of the following: when the access request belongs to an ongoing transaction, receiving an acceptance of the access request from the database system; and when the access request does not belong to an ongoing transaction, receiving a rejection of the access request from the database system. The method may also include: receiving a message from the first application instance, the message including a transaction identifier indicating that the message belongs to an ongoing transaction. The access request may include a transaction identifier indicating the transaction to which the access request belongs. The method may also include triggering the sending of a transaction end request indicating the end of the transaction to the database system. The system may be a mobile communication system, and the database system may be a central database system employed in the mobile communication system.

[0019] According to a fourth aspect, a computer program product is provided. The computer program product includes a program code portion, which is used to perform the method of at least one of the first, second and third aspects when the computer program product is executed on one or more computing devices (e.g., a processor or a distributed set of processors). The computer program product can be stored on a computer-readable recording medium (e.g., a semiconductor memory, a DVD, a CD-ROM, etc.).

[0020] According to a fifth aspect, there is provided a computing unit configured to execute a database system for concurrency control of transactions in a system, the system comprising a plurality of application instances accessing the database system. The computing unit comprises at least one processor and at least one memory, the at least one memory comprising instructions executable by the at least one processor, so that the database system is operable to perform any of the method steps proposed herein for the first aspect.

[0021] According to a sixth aspect, there is provided a computing unit configured to execute a first application instance for concurrency control of transactions in a system, the system comprising a plurality of application instances accessing a database system. The computing unit comprises at least one processor and at least one memory, the at least one memory comprising instructions executable by the at least one processor, so that the first application instance is operable to perform any of the method steps proposed herein for the second aspect.

[0022] According to a seventh aspect, there is provided a computing unit configured to execute a second application instance for concurrency control of transactions in a system, the system comprising a plurality of application instances accessing a database system. The computing unit comprises at least one processor and at least one memory, the at least one memory comprising instructions executable by the at least one processor, so that the second application instance is operable to perform any of the method steps proposed herein for the third aspect.

[0023] According to an eighth aspect, a system is provided, the system comprising the computing unit of the fifth aspect, the computing unit of the sixth aspect and the computing unit of the seventh aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Embodiments of the technology presented herein are described below with reference to the accompanying drawings, in which:

[0025] Figure 1 A signaling diagram illustrating an exemplary process requiring concurrency control;

[0026] Figure 2 shows a signalling diagram illustrating the use of strict locking;

[0027] Figure 3 is a signaling diagram illustrating the use of OCC;

[0028] Figures 4a to 4c An exemplary composition of a computing unit configured to execute a database system, a computing unit configured to execute a first application instance, and a computing unit configured to execute a second application instance according to the present disclosure is shown;

[0029] Figure 5 A method that may be performed by a database system according to the present disclosure is shown;

[0030] Figure 6 A method that can be performed by a first application example according to the present disclosure is shown;

[0031] Figure 7 A method that can be performed by a second application example according to the present disclosure is shown;

[0032] Figure 8A signaling diagram showing an exemplary interaction between a database system, a first application instance, and a second application instance according to the present disclosure;

[0033] Fig. 9 A flowchart showing an exemplary race condition checking method according to the present disclosure; and

[0034] Fig.10 A signaling diagram showing exemplary interactions between a database system and several service instances is shown. Figure 1 Examples of and employing the technology of the present disclosure therein. DETAILED DESCRIPTION

[0035] In the following description, for the purpose of explanation rather than limitation, specific details are set forth in order to provide a comprehensive understanding of the present disclosure. However, it will be apparent to one skilled in the art that the present disclosure may be implemented in other embodiments that depart from these specific details.

[0036] Those skilled in the art will also appreciate that the steps, services, and functions explained below may be implemented using separate hardware circuits, using software functions in combination with a programmed microprocessor or general purpose computer, using one or more application specific integrated circuits (ASICs), and / or using one or more digital signal processors (DSPs). It will also be appreciated that when the present disclosure is described in terms of methods, the present disclosure may also be embodied in one or more processors and one or more memories coupled to the one or more processors, wherein the one or more memories are encoded with one or more programs that, when executed by the one or more processors, perform the steps, services, and functions disclosed herein.

[0037] Figure 4a Schematically illustrates an exemplary composition of a computing unit 400, which is configured to execute a database system for concurrency control of transactions in a system, the system including a plurality of application instances accessing the database system. The computing unit 400 includes at least one processor 402 and at least one memory 404, wherein the at least one memory 404 contains instructions executable by the at least one processor 402, so that the database system is operable to perform the method steps described herein below with reference to the database system.

[0038] Figure 4bThe exemplary composition of a computing unit 410 is schematically shown, and the computing unit 410 is configured to execute a first application instance for concurrency control of transactions in a system, the system including multiple application instances accessing a database system. The computing unit 410 includes at least one processor 412 and at least one memory 414, wherein the at least one memory 414 contains instructions executable by the at least one processor 412, so that the first application instance is operable to perform the method steps described herein below with reference to the first application instance.

[0039] Figure 4c The exemplary composition of a computing unit 420 is schematically shown, and the computing unit 420 is configured to execute a second application instance for concurrency control of transactions in a system, the system including multiple application instances accessing a database system. The computing unit 420 includes at least one processor 422 and at least one memory 424, wherein the at least one memory 424 contains instructions executable by the at least one processor 422, so that the second application instance is operable to perform the method steps described herein below with reference to the second application instance.

[0040] It will be understood that, for example, each of computing unit 400, computing unit 410, and computing unit 420 may be implemented on a physical computing unit or a virtualized computing unit (e.g., a virtual machine). It will also be understood that each of computing unit 400, computing unit 410, and computing unit 420 may not necessarily be implemented on an independent computing unit, but may also be implemented as a component implemented in software and / or hardware that resides on multiple distributed computing units (e.g., in a cloud computing environment).

[0041] Figure 5 A method according to the present disclosure that can be performed by a database system executed on a computing unit 400 is shown. The method is dedicated to parallelism control of transactions in an execution system, and the system includes multiple application instances accessing the database system. In step S502, the database system can receive a transaction start request indicating the start of a transaction from a first application instance in the multiple application instances (e.g., a first application instance executed on the computing unit 410) to lock data stored in the database system for access requests that do not belong to the transaction while the transaction is in progress. In step S504, the database system can receive an access request to at least a portion of the data from a second application instance in the multiple application instances (e.g., a second application instance executed on the computing unit 420) while the transaction is in progress. In step S506, the database system can control the acceptance of the access request based on checking whether the access request belongs to the transaction. In step S508, the database system can receive a transaction end request indicating the end of the transaction.

[0042] Multiple application instances accessing a database system may include instances of one or more applications. Multiple application instances may access the database system simultaneously, so that transactions may be used to handle competition conditions that occur when accessing the database system. For example, the database system may correspond to a database management system (DBMS), but is not limited thereto, and it will be understood that the database system may generally correspond to any other application logic executed on a layer above the database. Each transaction may include one or more access requests (e.g., read and / or write requests) to the database system, each of which may be executed by one of the multiple application instances. The access requests of a transaction may not necessarily originate from the same application instance, but one or more access requests may include access requests from different application instances (possibly even from instances of different types of applications) in the multiple application instances. If all of the access requests in the one or more access requests are themselves successful (e.g., no side effects caused by competition conditions occur), the transaction may be considered successful.

[0043] According to step S502, a transaction may be initiated by a transaction start request, which indicates the start of a transaction and causes the database system to lock data stored in the database system for access requests that do not belong to the transaction while the transaction is ongoing. Therefore, rather than locking the data exclusively by the first application instance from which the transaction start request is received, the data may be locked based on the transaction itself, so that the acceptance of access requests to at least a portion of the data (which are received according to step S504) may be controlled based on checking whether the access request belongs to the ongoing transaction according to step S506. In this way, locking of data and authorization of access to data may be managed by the database system itself, so that locking may be transaction-specific, rather than application instance-specific (e.g., as is the case in the above-described strict locking technique).

[0044] Based on the result of checking whether the access request belongs to a transaction, the access request may be accepted or rejected. Thus, controlling the acceptance of the access request may include one of: accepting the access request when the access request belongs to a transaction; and rejecting the access request when the access request does not belong to a transaction. Since the lock on data is not exclusive to a specific application instance, the first application instance from which the transaction start request is received may be different from the second application instance from which the access request is received. The first application instance and the second application instance may even be instances of different types of applications.

[0045] In order to identify whether the access request belongs to an ongoing transaction, a transaction identifier may be assigned to the transaction, and the access request may include the transaction identifier, which may be checked for a match with a transaction identifier of the ongoing transaction. In one variant, the transaction start request may therefore include a first transaction identifier uniquely identifying a transaction, and the access request may include a second transaction identifier indicating the transaction to which the access request belongs, wherein checking whether the access request belongs to the transaction may include comparing the first transaction identifier and the second transaction identifier. When the first transaction identifier and the second transaction identifier match, the access request may be accepted, otherwise rejected.

[0046] The database system may store the first transaction identifier upon receiving the transaction start request for later comparison with a transaction identifier included in a subsequent access request. In one embodiment, the first transaction identifier may be stored in association with the data to be locked, so that when an access request attempts to access at least a portion of the data, it may be checked whether the transaction identifier included in the access request matches the first transaction identifier stored in association with the data. In other words, locking the data may include marking the data with the first transaction identifier, wherein the first transaction identifier may be obtained based on the marking of at least a portion of the data to be accessed by the access request before comparing the first transaction identifier to the second transaction identifier.

[0047] The access request may correspond to a read request or a write request. Since typically only write requests may cause inconsistencies in the data when a race condition occurs, the lock may only be applied to write requests. Thus, the access request received from the second application instance may be a write request, wherein read requests for data from multiple application instances may be accepted regardless of whether the read request belongs to a transaction.

[0048] The data to be locked may be specified in different ways. In one variant, the data to be locked may be specified on the request of the first application instance when sending a transaction start request, for example, the transaction start request may include an indication of the data to be locked while the transaction is in progress. In another variant that may replace or be in addition to the previous variant, the data to be locked may be marked each time a database access is performed as part of an ongoing transaction, for example, the data to be locked may include data subject to a read request performed as part of an ongoing transaction. In a specific such variant, the first read request may be given by the transaction start request itself, that is, the transaction start request may correspond to an initial read request performed as part of a transaction. The data to be locked may include one or more records, and in a specific variant, the data to be locked may include one or more attributes of a record of a database system. In this variant, only specific attributes to be accessed by the access request that may be subject to potential competition conditions may be marked as being locked. Therefore, one or more attributes of a record may correspond to a subset of attributes in a plurality of attributes of the record, wherein the attribute subset includes the following attributes: attributes that are identified as being subject to competition conditions in an ongoing transaction. In this way, control can be limited to a minimal set of attributes, which is advantageous because many attributes can often be updated at once in a database access, but only a few attributes need to be controlled for potential race conditions with other transactions. For example, attributes that may be subject to race conditions in an ongoing transaction can be identified from the application logic of the first application instance that sends a transaction start request.

[0049] When the lock on the data is to be released, according to step S508, the database system may receive a transaction end request indicating the end of the transaction. Upon receiving the transaction end request, the database system may release the lock on the data. The transaction end request may be received from one of the first application instance that sent the transaction start request and the second application instance that sent the access request. As described above, since the lock on the data may not be exclusive to a specific application instance, the transaction end request may also be received from a third application instance among the multiple application instances, wherein the third application instance may be different from the first application instance (and different from the second application instance).

[0050] The system including multiple application instances and a database system may be a mobile communication system, and the database system may be a central database system employed in the mobile communication system. For example, the mobile communication system may include a cellular network such as a 5G network, and the database system may be, for example, a database system storing session context information for UEs registered with the mobile communication system. The application instance may correspond to an instance of a service according to the SBA paradigm, for example, provided in a network domain of the mobile communication system.

[0051] Figure 6 4 shows a method according to the present disclosure that can be performed by a first application instance executed on computing unit 410. The method is dedicated to performing concurrency control of transactions in a system including multiple application instances accessing a database system (e.g., a database system executed on computing unit 400). The operation of the first application instance can be used as a reference to the above Figure 5 The operations of the database system described above are supplementary, and therefore, the various aspects described above with respect to the operations of the first application instance may also be applicable to the operations of the first application instance executed on the computing unit 410 described below. Therefore, unnecessary repetition will be omitted below.

[0052] In step S602, the first application instance may trigger sending a transaction start request indicating the start of a transaction to the database system, so that the database system locks the data stored in the database system for access requests that do not belong to the transaction while the transaction is in progress. In step S604, the first application instance may trigger sending a transaction end request indicating the end of the transaction to the database system.

[0053] As mentioned above about Figure 5 As described, the transaction start request may include a transaction identifier that uniquely identifies the transaction. The transaction start request may include an indication of the data to be locked while the transaction is in progress. Moreover, the transaction start request may correspond to an initial read request executed as part of the transaction. The data to be locked may include one or more attributes of a record of a database system. The one or more attributes of the record may correspond to a subset of attributes in a plurality of attributes of the record, wherein the attribute subset includes the following attributes: attributes that are identified as attributes that may be subject to a competitive condition in an ongoing transaction. The first application instance may also trigger the sending of a message including a transaction identifier to the second application instance, the transaction identifier indicating to the second application instance that the message belongs to an ongoing transaction. By including the transaction identifier in the message sent to the second application instance, the second application instance may know that the message belongs to an ongoing transaction, and therefore the second application instance may then include the transaction identifier in other messages sent by itself, thereby conveying transactional information to other application instances, generating a message stream subject to the same transaction. The system may be a mobile communication system, and the database system may be a central database system employed in the mobile communication system.

[0054] Figure 7 4 shows a method according to the present disclosure that can be performed by a second application instance executed on computing unit 420. The method is dedicated to executing concurrency control of transactions in a system including multiple application instances accessing a database system (e.g., a database system executed on computing unit 400). The operation of the second application instance can be used as a reference to the above Figure 5 The operation of the database system described above and / or Figure 6 The operations of the first application example described above are supplementary, and therefore, the above aspects of the operations of the second application example can also be applied to the operations of the second application example described below. Therefore, unnecessary repetition will be omitted below.

[0055] In step S702, the second application instance may trigger sending an access request to the database system for at least a portion of the data stored in the database system. For access requests that do not belong to an ongoing transaction, the data is locked by the database system. In step S704, the second application instance may receive an acceptance of the access request from the database system when the access request belongs to an ongoing transaction, or receive a rejection of the access request from the database system when the access request does not belong to an ongoing transaction. In step S706, the second application instance may trigger sending a transaction end request to the database system indicating the end of the transaction.

[0056] As mentioned above about Figure 5 and Figure 6 As described, the access request may include a transaction identifier indicating the transaction to which the access request belongs. The second application instance may also receive a message including a transaction identifier from the first application instance, the transaction identifier indicating that the message belongs to an ongoing transaction. The transaction identifier included in the access request may correspond to the transaction identifier received in the message from the first application instance, so that the transaction identifier may correspond to transactional information sent along a message flow subject to the ongoing transaction. When the transaction identifier included in the access request corresponds to a different transaction identifier, the access request may belong to a transaction different from the ongoing transaction. The system may be a mobile communication system, and the database system may be a central database system employed in the mobile communication system.

[0057] Figure 8 A signaling diagram of exemplary interactions between a database system, a first application instance, and a second application instance according to the present disclosure is shown. Figure 8 In the example, the database system is represented by reference numeral 802 and corresponds to a UE session context database of the mobile communication system, the first application instance is represented by reference numeral 804 and corresponds to an instance X of a service A provided in the mobile communication system, and the second application instance is represented by reference numeral 806 and corresponds to an instance Y of service A (or another service B) provided in the mobile communication system.

[0058] In step 1 of the process, the first application instance 804 may send a transaction start request to the database system 802, the transaction start request including a first transaction identifier Id1 and an indication of the data to be locked, which in the example shown is a list of attributes (attributes 1, 2, 3). As shown, the transaction start request may appear in the form of a read request, for example, for reading the value of the requested attribute. Upon receiving the transaction start request, the database system 802 may save the requested attribute in association with the first transaction identifier Id1, send back an acknowledgement, and return the requested attribute value to the first application instance 804. It should be noted that the lock for the requested attribute may not be exclusive to the first application instance 804, but exclusive to the first transaction identified by the identifier Id1. If the attribute list is not specified in the transaction start request, the data to be locked may include data that is subject to subsequent read requests executed as part of the first transaction with the identifier Id1.

[0059] In step 2, the second application instance 806 may similarly send a transaction start request to the database system 802, the transaction start request including the second transaction identifier Id2 and an indication of the data to be locked, which in the example shown is a list of attributes 1, 4, and 5. The transaction start request may also appear in the form of a read request, for example, for reading the values ​​of the requested attributes 1, 4, and 5. Upon receiving the transaction start request, the database system 802 may save the requested attributes in association with the second transaction identifier Id2, and send back an acknowledgement, as well as return the requested attribute values ​​to the second application instance 806. It should be noted that the list of attributes 1, 2, and 3 that is subject to the first transaction with identifier Id1 overlaps with the list of attributes 1, 4, and 5 that is subject to the second transaction with identifier Id2, but this does not trigger any specific operation at this stage.

[0060] In step 3, the second application instance 806 may send a write request for a specific attribute (i.e., attribute 2 in the example shown) to the database system 802, wherein the write request includes a second transaction identifier Id2, which indicates that the write request belongs to a second transaction with identifier Id2. The database system 802 may then perform a race condition (RC) check by comparing the first transaction identifier Id1 and the second transaction identifier Id2, and due to the mismatch of the identifiers, the database system 802 may detect that there is an attempt to write to attribute (2) locked by another transaction (i.e., the first transaction with identifier Id1). The database system 802 may therefore reject the write request by sending a failure indication to the second application instance 806 in step 4.

[0061] After completing all database updates within the first transaction with identifier Id1, in step 5, the first application instance 804 can send a transaction end request to the database system 802, which indicates the end of the first transaction with identifier Id1. In the example shown, the transaction end request can also appear in the form of a read request. Upon receiving the transaction end request, the database system 802 can remove the attribute list for the first transaction with identifier Id1 and stop the transaction accordingly. Since there are no longer overlapping lock attributes for the second transaction with identifier Id2, any other write requests executed as part of the second transaction with identifier Id2 will now succeed, as exemplarily shown in step 6 in the figure. Such a request can be triggered, for example, by a timer started at the second application instance 806 after the last unsuccessful request attempt (e.g., the attempt in step 3), or by a direct callback from the database system 802 after step 5.

[0062] In this example, it will be appreciated that between steps 1 and 5, other interactions may occur between the first application instance 804 and the second application instance 806 and possibly other application instances (not shown for simplicity). Figure 8 ). Furthermore, it will be understood that the transaction end request does not necessarily have to be sent from the first application instance 804, but may also be sent from another application instance (possibly belonging to a service different from services A and B) involved in the first transaction with identifier Id1.

[0063] Fig. 9 A flow chart of an exemplary race condition checking method that can be performed by the database system 802 is shown. In essence, the method may include: for an access request (a write request in the example shown) received for a transaction with an identifier IdX, comparing the transaction identifier IdX with a transaction identifier stored in association with the data to be accessed. More specifically, if the data to be accessed corresponds to one or more attributes, it can be checked whether the attributes are stored for other transactions, and if so, it can be checked whether there is an overlap with these attributes. If there is an overlap, the access request can be denied. Otherwise, if there are no attributes for the transaction, or if there is no overlap between the attributes, the access request can be accepted. As an exemplary embodiment of these two determination processes, it is conceivable that upon receiving a list of attributes to be controlled, the database system 802 applies a tag to the requested attribute together with the corresponding transaction identifier. Then, when an access request arrives, the database system 802 can check these tags, and if there is a tag with a different transaction identifier, the access request can be denied.

[0064] Fig.10A signaling diagram showing exemplary interactions between a database system and several service instances is shown. The signaling diagram is based on the above description of Figure 1 The example described here provides concurrency control for it. Fig.10 The signaling diagram is basically equivalent to Figure 1 , and therefore only the differences will be described below.

[0065] In step 1 of the process, an instance of service A starts a new transaction and marks the read request as a transaction start request including a transaction Id. The instance may also mark data that may be subject to race conditions, i.e., data that will invalidate the transaction if modified during the transaction. In the example shown, attribute Y is marked. It is worth mentioning here that, in practice, update operations on a database may include multiple attributes (e.g., in the Lightweight Directory Access Protocol (LDAP), updates may be performed on entries that may hold even hundreds of attributes), but not all attributes may invalidate the transaction when changed. It may therefore be advantageous to mark only the individual attributes that are potentially subject to race conditions. This can typically be known from the application logic of the service / application that performs the update.

[0066] In step 3, the instance of service A tags the sent message (NservC operation request) with a transaction Id to designate the message as belonging to the ongoing transaction. When the instance of service C receives the message, it may know that it needs to include the transaction Id in the access request to the UE session context database, which is executed as part of the transaction. Therefore, in step 4a, the instance of service C includes the transaction Id in the write request for attribute X, which will therefore be saved by the database as an attribute to be locked under the ongoing transaction. In step 4b, when a write request for attribute Y is received (to update attribute Y to a different value from A), the database may realize that the locked attribute (attribute Y was locked in step 1) is about to be modified while the transaction is still in progress, so the database rejects the request by sending a failure indication in step 6. In step 7, the instance of service A may close the transaction to the database, which in turn may release control of the attributes under the transaction.

[0067] As is apparent from the above, the present disclosure provides a technique for concurrency control of transactions in a system including multiple application instances accessing a database system. According to the proposed technique, the database system may control the handling of race conditions, rather than the application instances accessing the database controlling the handling of race conditions, and thus a situation where data is exclusively blocked by a single application instance during the entire transaction completion may be avoided. The result of the proposed race condition handling may be that data such as attribute lists may be effectively protected until the transaction is completed. Since the proposed technique may not allow modification of such data, a rollback mechanism may not be required. In addition, the proposed technique may allow selection of a minimum set of attributes to be controlled by carefully selecting those attributes that may be subject to race conditions, wherein the selection may not be limited to only those attributes modified by a given transaction.

[0068] The techniques presented herein can generally provide a fast and simple method for handling race conditions, which can be particularly useful in environments where complex multi-step transactions occur and data contention is generally low, such as in 5G core networks. Since the techniques presented herein can impose limited design constraints on the application logic of services that perform database updates, the techniques can form a candidate for a standard solution in a multi-vendor environment. The application instance itself may not be required to handle race conditions because the logic can essentially be set in the database. Therefore, rollback functionality can generally be avoided by essentially serializing transactions using database functionality. In addition to write access requests, read access requests to the data involved can always be authorized for concurrent transactions during the execution of an ongoing transaction.

[0069] Furthermore, requests within an ongoing transaction can typically be executed by different instances (of the same or different services) that can access the same data, the only requirement being that a transaction identifier may need to be included in the access request. Thus, locking can be exclusive not to an application instance, but to the transaction itself. In other words, every other application instance that shares the same data can perform a write, provided it belongs to the same transaction. A collection of instances of the same service type, or any service instance in a pool, can access the database with relatively easy management of contention conditions. This can even simplify aspects such as routing and load balancing in the system, for example.

[0070] It is believed that the advantages of the technology presented herein will be fully understood from the foregoing description, and it will be apparent that various changes may be made to the form, structure and arrangement of the exemplary aspects thereof without departing from the scope of the invention or sacrificing all of its advantageous effects. Because the technology presented herein may be varied in many ways, it will be appreciated that the invention should be limited only by the scope of the appended claims.

Claims

1. A method for concurrency control of transactions in a system, the system comprising a plurality of application instances (804, 806) accessing a database system (802), the method being executed by the database system (802) and comprising: Receiving (S502) a transaction start request indicating the start of a transaction from a first application instance (804) of the plurality of application instances (804, 806) to lock data stored in the database system (802) for access requests that do not belong to the transaction while the transaction is in progress, the transaction start request including a first transaction identifier that uniquely identifies the transaction; While the transaction is in progress, receiving (S504) an access request for at least a portion of the data from a second application instance (806) of the plurality of application instances (804, 806), the access request comprising a second transaction identifier indicating a transaction to which the access request belongs; as well as controlling (S506) acceptance of the access request based on checking whether the access request belongs to the transaction, wherein checking whether the access request belongs to the transaction comprises comparing the first transaction identifier with the second transaction identifier, The first transaction identifier is included in a message sent by the first application instance (804) to the second application instance (806), and the first transaction identifier indicates to the second application instance (806) that the message belongs to an ongoing transaction.

2. The method according to claim 1, wherein: Controlling (S506) the acceptance of the access request includes one of the following: When the access request belongs to the transaction, accepting the access request, and When the access request does not belong to the transaction, the access request is rejected.

3. The method according to claim 1, wherein: The first application instance (804) is different from the second application instance (806).

4. The method according to claim 3, wherein: The first application instance (804) and the second application instance (806) are instances of different types of applications.

5. The method according to claim 1, wherein: Locking the data includes marking the data with the first transaction identifier, and wherein the first transaction identifier is obtained based on the marking of the at least a portion of the data to be accessed by the access request before comparing the first transaction identifier to the second transaction identifier.

6. The method according to claim 1, wherein: The access request is a write request, and wherein read requests for the data from the plurality of application instances (804, 806) are accepted regardless of whether the read requests belong to the transaction.

7. The method according to claim 1, wherein: The transaction start request includes an indication of data to be locked while the transaction proceeds.

8. The method according to claim 1, wherein: The data to be locked includes data that is subject to a read request performed as part of an ongoing transaction.

9. The method according to claim 1, wherein: The transaction start request corresponds to an initial read request executed as part of the transaction.

10. The method according to claim 1, wherein: The data to be locked includes one or more attributes of a record of the database system (802).

11. The method according to claim 10, wherein: The one or more attributes of the record correspond to a subset of attributes among a plurality of attributes of the record, and wherein the subset of attributes includes attributes identified as being subject to a race condition in an ongoing transaction.

12. The method according to claim 1, further comprising: A transaction end request indicating the end of the transaction is received (S508).

13. The method according to claim 12, wherein: The transaction end request is received from a third application instance of the plurality of application instances (804, 806), the third application instance being different from the first application instance (804).

14. The method according to claim 1, wherein: The system is a mobile communication system, and the database system (802) is a central database system employed in the mobile communication system.

15. A method for concurrency control of transactions in a system, the system comprising a plurality of application instances (804, 806) accessing a database system (802), the method being performed by a first application instance (804) of the plurality of application instances (804, 806), and comprising: triggering (S602) sending a transaction start request indicating the start of a transaction to the database system (802), so that the database system (802) locks data stored in the database system (802) for access requests that do not belong to the transaction while the transaction is in progress, The transaction start request includes a transaction identifier that uniquely identifies the transaction, the transaction identifier is used by the database system (802) to compare with a second transaction identifier included in an access request received from a second application instance (806) of the plurality of application instances (804, 806) when the transaction is in progress, the second transaction identifier indicating the transaction to which the access request belongs, Wherein, the method further comprises: The sending of a message including the transaction identifier to the second application instance (806) is triggered, the transaction identifier indicating to the second application instance (806) that the message belongs to an ongoing transaction.

16. The method according to claim 15, wherein: The transaction start request includes an indication of data to be locked while the transaction proceeds.

17. The method according to claim 15, wherein: The transaction start request corresponds to an initial read request executed as part of the transaction.

18. The method according to claim 15, wherein: The data to be locked includes one or more attributes of a record of the database system (802).

19. The method according to claim 18, wherein: The one or more attributes of the record correspond to a subset of attributes among a plurality of attributes of the record, and wherein the subset of attributes includes attributes identified as being subject to a race condition in an ongoing transaction.

20. The method of claim 15, further comprising: The trigger (S604) sends a transaction end request to the database system (802) indicating the end of the transaction.

21. The method according to claim 15, wherein: The system is a mobile communication system, and the database system (802) is a central database system employed in the mobile communication system.

22. A method for concurrency control of transactions in a system, the system comprising a plurality of application instances (804, 806) accessing a database system (802), the method being performed by a second application instance (806) of the plurality of application instances (806, 806), and comprising: triggering (S702) sending to the database system (802) an access request for at least a portion of the data stored in the database system (802), wherein for access requests not belonging to the ongoing transaction, the data is locked by the database system (802), wherein the access request includes a transaction identifier indicating a transaction to which the access request belongs, the transaction identifier being used by the database system (802) to compare with a first transaction identifier included in a transaction start request received from a first application instance (804) of the plurality of application instances (804, 806) indicating the start of the ongoing transaction, the first transaction identifier uniquely identifying the ongoing transaction, Wherein, the method further comprises: A message is received from the first application instance (804), the message including a transaction identifier indicating that the message belongs to an ongoing transaction.

23. The method according to claim 22, further comprising one of the following: receiving (S704) an acceptance of the access request from the database system (802), when the access request belongs to the ongoing transaction, and When the access request does not belong to the ongoing transaction, a rejection of the access request is received (S704) from the database system (802).

24. The method of claim 22, further comprising: The trigger ( S706 ) sends a transaction end request to the database system ( 802 ) indicating the end of the transaction.

25. The method according to claim 22, wherein: The system is a mobile communication system, and the database system (802) is a central database system employed in the mobile communication system.

26. A computer program product comprising program code portions for performing the method of any one of claims 1 to 25 when the computer program product is executed on one or more computing devices.

27. The computer program product of claim 26, stored on a computer readable recording medium.

28. A computing unit (400) configured to execute a database system (802) for concurrency control of transactions in a system, the system comprising a plurality of application instances (804, 806) accessing the database system (802), the computing unit (400) comprising at least one processor (402) and at least one memory (404), the at least one memory (404) containing instructions executable by the at least one processor (402), so that the database system (802) is operable to execute the method of any one of claims 1 to 14.

29. A computing unit (410) configured to execute a first application instance (804) for concurrency control of transactions in a system, the system comprising a plurality of application instances (804, 806) accessing a database system (802), the computing unit (410) comprising at least one processor (412) and at least one memory (414), the at least one memory (414) containing instructions executable by the at least one processor (412), so that the first application instance (804) is operable to execute the method of any one of claims 15 to 21.

30. A computing unit (420) configured to execute a second application instance (806) for concurrency control of transactions in a system, the system comprising a plurality of application instances (804, 806) accessing a database system (802), the computing unit (420) comprising at least one processor (422) and at least one memory (424), the at least one memory (424) containing instructions executable by the at least one processor (422), so that the second application instance (806) is operable to execute the method of any one of claims 22 to 25.

31. A system comprising a computing unit (400) according to claim 28, a computing unit (410) according to claim 29 and a computing unit (420) according to claim 30.

Images