A transaction object allocation method for a relational in-memory database

Abstract

This invention provides a method for allocating transaction objects in a relational in-memory database. The method includes: obtaining a target maximum transaction concurrency; when the relational in-memory database starts, initializing a transaction object memory pool according to the target maximum transaction concurrency to obtain an initialized transaction object memory pool; obtaining transaction objects according to the target maximum transaction concurrency and associating the transaction objects with the initialized transaction object memory pool to obtain a global transaction linked list; dividing the global transaction linked list according to the obtained number of physical cores to obtain a target thread-private transaction linked list; the target thread-private transaction linked list includes at least a first thread-private transaction linked list and a second thread-private transaction linked list; allocating idle transaction objects in the target thread-private transaction linked list according to received transaction execution requests to obtain an allocation result. This invention is beneficial for improving the allocation efficiency of transaction objects.

Description

Technical Field

[0001] This invention relates to the field of database technology, and also to a method for allocating transaction objects in a relational in-memory database. Background Technology

[0002] Relational in-memory databases load all data into memory, resulting in transaction processing latency down to the microsecond level. However, memory resources are limited, and frequent allocation and deallocation can lead to memory fragmentation. Fine-grained management of the transaction lifecycle is necessary, especially the memory allocation and usage of transaction objects. Current technologies, however, require traversing the entire transaction list when allocating transaction objects. In high-concurrency scenarios (tens of thousands of transactions per second), this can cause CPU bottlenecks, violating the low-latency requirements of in-memory databases. Furthermore, when multiple threads operate on the transaction object list, traditional solutions use global mutexes, leading to concurrent blocking during transaction state transitions (such as switching from active to idle and then to committed), reducing transaction throughput. Therefore, current technologies cannot meet the core requirements of relational in-memory databases—high concurrency, low latency, and memory sensitivity—resulting in low transaction processing efficiency. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a method for allocating transaction objects in relational in-memory databases, so as to improve the allocation efficiency and processing efficiency of transaction objects.

[0004] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0005] A first aspect of the present invention provides a method for allocating transaction objects in a relational in-memory database, comprising:

[0006] Get the target maximum number of concurrent transactions;

[0007] When the relational in-memory database starts, the transaction object memory pool is initialized according to the target maximum transaction concurrency, resulting in an initialized transaction object memory pool.

[0008] Obtain transaction objects according to the target maximum transaction concurrency, and associate the transaction objects with the initialized transaction object memory pool to obtain a global transaction linked list;

[0009] The global transaction list is divided according to the obtained number of physical cores to obtain the target thread private transaction list; the target thread private transaction list includes at least the first thread private transaction list and the second thread private transaction list.

[0010] Based on the received transaction execution request, the idle transaction objects in the target thread's private transaction linked list are allocated to obtain the allocation result.

[0011] Optionally, obtain the target maximum transaction concurrency, including:

[0012] Get the original maximum concurrent transaction count as input by the user;

[0013] The original maximum transaction concurrency is adjusted according to preset constraints to obtain the target maximum transaction concurrency.

[0014] Optionally, when the relational in-memory database starts, the transaction object memory pool is initialized according to the target maximum transaction concurrency, resulting in an initialized transaction object memory pool, including:

[0015] When the relational in-memory database starts, the memory requirements of the transaction object memory pool are calculated based on the target maximum transaction concurrency.

[0016] Based on the aforementioned memory requirements, determine the memory region data;

[0017] The transaction object memory pool is initialized based on the memory region data to obtain the initialized transaction object memory pool.

[0018] Optionally, transaction objects are obtained according to the target maximum transaction concurrency, and the transaction objects are associated with the initialized transaction object memory pool to obtain a global transaction linked list, including:

[0019] Obtain transaction objects according to the target maximum transaction concurrency;

[0020] The transaction object is identified by attributes based on the initialized transaction object memory pool, and a global transaction linked list is obtained.

[0021] Optionally, the transaction object is identified by attributes based on the initialized transaction object memory pool to obtain a global transaction linked list, including:

[0022] The transaction object is assigned a transaction identifier according to the initialized transaction object memory pool, resulting in a transaction object with a transaction identifier;

[0023] The transaction object with the transaction identifier is marked with a status to obtain the transaction object with the status identifier;

[0024] The transaction objects with status identifiers are associated to obtain a global transaction linked list.

[0025] Optionally, the global transaction list is divided according to the obtained number of physical cores to obtain the target thread's private transaction list, including:

[0026] Obtain the number of physical cores; the number of physical cores refers to the number of physical cores of the central processing unit of the current server.

[0027] The global transaction list is divided according to the number of physical cores to obtain the target thread private transaction list; the number of the target thread private transaction lists is the same as the number of physical cores.

[0028] Optionally, based on the received transaction execution request, an idle transaction object in the target thread's private transaction list is allocated to obtain an allocation result, including:

[0029] Receive transaction execution requests;

[0030] According to the transaction execution request, the first thread private transaction list is locked, and when the first free transaction object is found in the first thread private transaction list, the first free transaction object is marked as being in use, and the first thread private transaction list is unlocked.

[0031] If no first free transaction object is found in the first thread's private transaction list, the second thread's private transaction list is locked. If a second free transaction object is found in the second thread's private transaction list, the second free transaction object is marked as being in use, and the second thread's private transaction list is unlocked.

[0032] Optionally, the allocation of idle transaction objects in the target thread's private transaction list based on the received transaction execution request, to obtain the allocation result, further includes:

[0033] If the second free transaction object is not found in the second thread private transaction list, unlock the first thread private transaction list and the second thread private transaction list, and search for the first free transaction object or the second free transaction object when the preset waiting parameter is reached.

[0034] A second aspect of the present invention provides a computing device, comprising: a processor and a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method described in the first aspect.

[0035] A third aspect of the present invention provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method as described in the first aspect.

[0036] The above-described solution of the present invention has at least the following beneficial effects:

[0037] The above-described solution of the present invention, by obtaining the target maximum transaction concurrency, initializes the transaction object memory pool according to the target maximum transaction concurrency when the relational in-memory database starts, obtains the initialized transaction object memory pool, then obtains transaction objects according to the target maximum transaction concurrency, and associates the transaction objects with the initialized transaction object memory pool to obtain a global transaction linked list. The global transaction linked list is divided according to the obtained number of physical cores to obtain a target thread private transaction linked list. The target thread private transaction linked list includes at least a first thread private transaction linked list and a second thread private transaction linked list. Finally, the idle transaction objects in the target thread private transaction linked list are allocated according to the received transaction execution requests to obtain the allocation result. This not only improves the allocation effect of transaction objects, but also greatly reduces the probability of memory fragmentation and lock contention problems of the global transaction linked list, which is conducive to improving transaction processing efficiency. Attached Figure Description

[0038] Figure 1 This is a flowchart illustrating the transaction object allocation method for a relational in-memory database according to an embodiment of the present invention. Detailed Implementation

[0039] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0040] like Figure 1 As shown, an embodiment of the present invention proposes a method for allocating transaction objects in a relational in-memory database, comprising the following steps:

[0041] Step 101: Obtain the target maximum number of concurrent transactions;

[0042] Step 102: When the relational in-memory database starts, the transaction object memory pool is initialized according to the target maximum transaction concurrency, and the initialized transaction object memory pool is obtained.

[0043] Step 103: Obtain transaction objects according to the target maximum transaction concurrency, and associate the transaction objects with the initialized transaction object memory pool to obtain a global transaction linked list;

[0044] Step 104: Divide the global transaction list according to the obtained number of physical cores to obtain the target thread private transaction list; the target thread private transaction list includes at least the first thread private transaction list and the second thread private transaction list.

[0045] Step 105: Allocate idle transaction objects in the target thread's private transaction list according to the received transaction execution request, and obtain the allocation result.

[0046] The transaction object allocation method for relational in-memory databases according to embodiments of the present invention obtains the target maximum transaction concurrency. When the relational in-memory database starts, it initializes a transaction object memory pool according to the target maximum transaction concurrency, obtaining an initialized transaction object memory pool. Then, it obtains transaction objects according to the target maximum transaction concurrency and associates these transaction objects with the initialized transaction object memory pool to obtain a global transaction list. The global transaction list is then divided according to the obtained number of physical cores to obtain a target thread-private transaction list. The target thread-private transaction list includes at least a first thread-private transaction list and a second thread-private transaction list. Finally, based on received transaction execution requests, idle transaction objects in the target thread-private transaction list are allocated to obtain the allocation result. This method not only improves the allocation efficiency of transaction objects but also significantly reduces memory fragmentation and lock contention issues in the global transaction list, thereby improving transaction processing efficiency.

[0047] In an optional embodiment of the present invention, step 101, obtaining the target maximum transaction concurrency, may include:

[0048] Step 1011: Obtain the original maximum concurrent transaction count input by the user;

[0049] Step 1012: Adjust the original maximum transaction concurrency according to preset constraints to obtain the target maximum transaction concurrency.

[0050] Specifically, the original maximum transaction concurrency can be set according to the user's own needs. After obtaining the original maximum transaction concurrency, it is necessary to adjust the original maximum transaction concurrency based on preset constraints such as hardware resources, business load, performance requirements, and database characteristics, so that the maximum transaction concurrency conforms to the actual situation and prevents the system resources from being exhausted.

[0051] Here, the preset constraints can include any of the following:

[0052] The maximum number of concurrent transactions shall not exceed the number of CPU logical cores multiplied by a preset value. If the transaction is CPU intensive, such as a complex query, the preset value can be 1. If the transaction mainly involves memory operations, such as a pure memory table update, the preset value can be 2. Depending on the actual situation, the preset value can also be 1.5.

[0053] The maximum number of concurrent transactions is in the range of: historical peak traffic × (1 + 20%) to historical peak traffic × (1 + 50%).

[0054] The maximum number of concurrent transactions cannot exceed the transaction pool capacity of the relational in-memory database.

[0055] The original maximum transaction concurrency is adjusted to meet preset constraints to obtain the target maximum transaction concurrency, so that the target maximum transaction concurrency is consistent with the actual situation, thus balancing performance and stability.

[0056] In an optional embodiment of the present invention, in step 102, when the relational in-memory database starts, the transaction object memory pool is initialized according to the target maximum transaction concurrency to obtain the initialized transaction object memory pool, which may include:

[0057] Step 1021: When the relational in-memory database starts, the memory requirement of the transaction object memory pool is calculated based on the target maximum transaction concurrency.

[0058] Specifically, the memory requirement of the transaction object memory pool is calculated based on the fact that the memory requirement of the transaction object memory pool is equal to the product of the target maximum number of concurrent transactions and the memory size of a single transaction object.

[0059] Step 1022: Determine the memory region data based on the memory requirements;

[0060] Specifically, a contiguous memory region (the physical carrier of the "memory pool") that meets the memory requirements is requested from the operating system. If it is an array, an array with a length equal to the number of concurrent connections is directly allocated, and the array elements are transaction objects. If it is a general-purpose memory pool, the entire memory block is allocated and then divided into several memory blocks according to the size of individual objects. Basic attributes of the memory pool are marked: starting address, total capacity, number of used / free memory blocks, memory block size, etc. Memory region data includes the basic attributes of the memory pool.

[0061] Step 1023: Initialize the transaction object memory pool according to the memory region data to obtain the initialized transaction object memory pool.

[0062] Specifically, the transaction object memory pool is initialized, including initializing the linked list pointers and setting the "next node" pointer of each object to null (to be used later to build a free linked list). It also includes initializing the synchronization mechanism by allocating a mutex lock / spin lock to each object / linked list (for concurrency control); context initialization by clearing the transaction context (such as transaction start time, associated sessions, operation data list, etc.); and verifying the initialization results to ensure that the attribute values ​​of all objects meet expectations (such as no null pointers).

[0063] In an optional embodiment of the present invention, step 103, obtaining transaction objects according to the target maximum transaction concurrency and associating the transaction objects with the initialized transaction object memory pool to obtain a global transaction linked list, may include:

[0064] Step 1031: Obtain transaction objects according to the target maximum transaction concurrency;

[0065] Specifically, if the target maximum transaction concurrency is 1024, then 1024 transaction objects will be obtained. Here, the obtained transaction objects can be pointers to transaction objects.

[0066] Step 1032: Identify the attributes of the transaction object according to the initialized transaction object memory pool to obtain a global transaction linked list.

[0067] In an optional embodiment of the present invention, step 1032 includes:

[0068] Step 10321: Allocate transaction identifiers to the transaction objects according to the initialized transaction object memory pool to obtain transaction objects with transaction identifiers;

[0069] Specifically, iterate through all transaction objects in the memory pool (number = target maximum transaction concurrency), assign transaction identifiers to each transaction object, and assign a unique transaction ID to each object (e.g., from 0 to concurrency number - 1, such as 0 to 99), thus obtaining transaction objects with transaction identifiers.

[0070] Step 10322: Mark the status of the transaction object with the transaction identifier to obtain the transaction object with the status identifier;

[0071] Specifically, iterate through all transaction objects in the memory pool, mark each one with a status, and mark all objects as "free" (meaning they are not used), thus obtaining transaction objects with status markings.

[0072] Step 10323: Perform association processing on the transaction objects with status identifiers to obtain a global transaction linked list.

[0073] Specifically, first, the transaction objects with status identifiers are validated to ensure that all object identifiers match expectations (e.g., correct status markings). Then, a management metadata structure for the memory pool is created, recording: the starting address of the memory pool, the total number of objects, the number of free objects, the head pointer of the free object linked list (pointing to the first free transaction object), the head pointer of the used object linked list (initially empty), and a concurrency control lock (used to protect global operations of the memory pool). All free transaction objects are chained together into a global free linked list via pointers (for easy subsequent allocation). Transaction objects with status identifiers are then populated into the global free linked list to obtain the global transaction linked list. Here, the association process can specifically involve associating the obtained transaction object pointers with the memory addresses of already initialized transaction objects in the initialized transaction object memory pool.

[0074] In an optional embodiment of the present invention, step 104, dividing the global transaction list according to the obtained number of physical cores to obtain the target thread's private transaction list, may include:

[0075] Step 1041, obtain the number of physical cores; the number of physical cores is the number of physical cores of the central processing unit of the current server;

[0076] Specifically, the number of physical cores of a central processing unit (CPU) refers to the number of chipsets on a single CPU that can process data.

[0077] Step 1042: Divide the global transaction list according to the number of physical cores to obtain the target thread private transaction list; the number of the target thread private transaction lists is the same as the number of physical cores.

[0078] Specifically, the global transaction list is divided according to the number of CPU physical cores to obtain a target thread-private transaction list with the same number of CPU physical cores. This reduces lock contention during concurrent allocation and avoids performance degradation caused by lock contention. In a specific embodiment, the steps for dividing the global transaction list include:

[0079] Based on the number of physical cores, an empty linked list is obtained that matches the number of physical cores. For example, if the number of physical cores is 4, then 4 empty linked list containers are created, numbered as follows: Core 0 private transaction linked list, Core 1 private transaction linked list, Core 2 private transaction linked list, and Core 3 private transaction linked list. The "head node pointer" and "tail node pointer" of each empty linked list are initialized, and the initial values ​​are all "empty" (indicating that there are no transaction objects). A corresponding relationship is formed, with the core number [0,1,2,3] corresponding to the private transaction linked list [empty, empty, empty, empty].

[0080] Lock the global transaction list to obtain a locked global transaction list. Here, a mutex lock is added to the global transaction list (to prevent data corruption caused by multi-threaded modification), locking the operation permissions of the global transaction list, during which other threads cannot modify the global list. Starting from the head node of the global transaction list (i.e., the first transaction object), each transaction object is pointed to in turn, such as the traversal order: transaction object 1001, transaction object 1002, transaction object 1003, transaction object 1004, transaction object 1005, transaction object 1006, transaction object 1007. When traversing to a certain transaction object, the "next node pointer" of the transaction object is saved first (to avoid losing subsequent nodes after splitting), and then the current transaction object is temporarily removed from the global list.

[0081] pass The core number to which the core belongs is calculated; where, The core ID is assigned, and its value ranges from [0, N-1]. The unique identifier for the transaction object in the global transaction list, where N is the number of physical cores. Modulo operation;

[0082] Based on the core ID, the transaction object in the global transaction list is inserted into the corresponding empty list to obtain the target thread's private transaction list, and the global transaction list is unlocked. Here, if the corresponding empty list is empty, the transaction object is set as the "head node" of the list, and the "tail node" is updated to this node; if the corresponding empty list is not empty, the transaction object is appended to the "tail node" of the list, and the "tail node" is updated to this transaction object (no need to traverse the list, just insert directly); after insertion, the connection between the transaction object and the global list is disconnected (the node's next pointer is set to null); after traversing the last transaction object (e.g., 1007) and allocating it, the "head node pointer" of the global transaction list is set to null; the mutex lock of the global transaction list is unlocked; the final state is: the global transaction list is empty, all 7 transaction objects are distributed in 4 empty lists, and the 4 empty lists containing transaction objects form the target thread's private transaction list.

[0083] In an optional embodiment of the present invention, step 105, allocating idle transaction objects in the target thread's private transaction list according to the received transaction execution request to obtain an allocation result, may include:

[0084] Step 1051: Receive transaction execution request;

[0085] Step 1052: Lock the first thread private transaction list according to the transaction execution request, and when the first free transaction object is found in the first thread private transaction list, mark the first free transaction object as in use and unlock the first thread private transaction list.

[0086] Step 1053: If no first free transaction object is found in the first thread private transaction list, lock the second thread private transaction list. If a second free transaction object is found in the second thread private transaction list, mark the second free transaction object as being in use and unlock the second thread private transaction list.

[0087] In an optional embodiment of the present invention, step 105, which involves allocating idle transaction objects in the target thread's private transaction list according to the received transaction execution request to obtain an allocation result, further includes:

[0088] Step 1054: If the second idle transaction object is not found in the second thread private transaction list, unlock the first thread private transaction list and the second thread private transaction list, and search for the first idle transaction object or the second idle transaction object when the preset waiting parameter is reached.

[0089] Specifically, in databases, a 1:N service model is typically used, where a single service thread concurrently executes transaction requests from multiple clients. At the start of a transaction, the thread's private transaction list (e.g., the first thread's private transaction list) is locked. Then, an available transaction slot (a transaction object that has not yet started execution, such as the first idle transaction object) is searched. If an available transaction slot exists, it is marked as being in use, and then the thread's private transaction list is unlocked.

[0090] If all transaction objects in the current thread's private transaction list (e.g., the first thread's private transaction list) are in use, then attempt to preempt the locks of other threads' private transaction lists (e.g., lock the second thread's private transaction list) and use the free transaction object in the second thread's private transaction list (e.g., the second free transaction object); if all transactions in the private transaction lists of all threads are in use (i.e., there are no free transaction objects in the first and second thread's private transaction lists), then relinquish CPU usage, wait for the next time slice, and repeat the transaction object search operation.

[0091] In one specific embodiment, locking and unlocking of thread-private transaction lists (such as the first thread-private transaction list or the second thread-private transaction list) are performed in the following manner:

[0092] If the thread is bound to the kernel, the corresponding first thread's private transaction list is directly retrieved; if the thread is not bound to the kernel, it is accessed through... The core ID is calculated; the corresponding first-thread private transaction linked list is then located based on the core ID. ;in, To be assigned to the core number, For hash functions, The unique identifier for the transaction object in the global transaction list, where N is the number of physical cores. Modulo operation is used; each thread has a private transaction list bound to a dedicated lock.

[0093] Check the current state of the lock in the corresponding first thread private transaction linked list. If it is unlocked, change the lock state to locked and, after finding the first free transaction object, change the lock state back to unlocked. If it is locked, check the current state of the lock in the second thread private transaction linked list and find the second free transaction object.

[0094] By using the above methods of object pre-allocation and fine-grained lock control of transaction object linked lists, the problems of memory fragmentation and lock contention in global transaction linked lists are greatly reduced.

[0095] A specific embodiment of the transaction object allocation method for relational in-memory databases according to this invention includes:

[0096] Step 111: Obtain the target maximum number of concurrent transactions;

[0097] Obtain the original maximum transaction concurrency input by the user, and then adjust it according to preset constraints to obtain the target maximum transaction concurrency that meets the preset constraints, thus preventing the system resources from being exhausted.

[0098] Step 112: When the relational in-memory database starts, the transaction object memory pool is initialized according to the target maximum transaction concurrency, and the initialized transaction object memory pool is obtained.

[0099] When a relational in-memory database starts up, it first calculates the memory requirements of the transaction object memory pool, then determines the data in the memory area based on this, and then initializes the transaction object memory pool to obtain the initialized transaction object memory pool.

[0100] Step 113: Obtain transaction objects according to the target maximum transaction concurrency, and associate the transaction objects with the initialized transaction object memory pool to obtain a global transaction linked list;

[0101] Obtain the transaction object pointer according to the target maximum transaction concurrency, and associate the transaction object pointer with the memory address of the initialized transaction object in the initialized transaction object memory pool to obtain the global transaction linked list.

[0102] Step 114: Divide the global transaction list according to the obtained number of physical cores to obtain the target thread private transaction list; the target thread private transaction list includes at least the first thread private transaction list and the second thread private transaction list;

[0103] The global transaction list is divided according to the number of CPU physical cores to obtain a target thread-private transaction list with the same number of CPU physical cores. This reduces lock contention during concurrent allocation and avoids performance degradation caused by lock contention. The target thread-private transaction list includes at least a first thread-private transaction list and a second thread-private transaction list.

[0104] Step 115: Allocate idle transaction objects in the target thread's private transaction list according to the received transaction execution request, and obtain the allocation result.

[0105] In databases, a 1:N service model is typically used, where a single service thread concurrently executes transaction requests from multiple clients. At the start of a transaction, the thread's private transaction list is locked first, then an available transaction slot (a transaction object that has not yet started execution) is searched. If an available transaction slot exists, it is immediately marked as USED, and the private transaction list is unlocked. If all transaction objects in the current thread's private transaction list are in the USED state, an attempt is made to acquire the locks of other threads' private transaction lists and use that transaction object; if all transactions in all threads' private transaction lists are in the USED state, CPU usage is relinquished, the thread waits for the next time slice, and the transaction object search operation is repeated.

[0106] The transaction object allocation method for relational in-memory databases according to this invention initializes the transaction object memory pool based on the user-defined maximum transaction concurrency parameter when the database instance starts, and associates all transaction objects with a global transaction object memory pool array. When the database instance shuts down, all transaction objects are destroyed and the memory resources of the memory pool are reclaimed. The management of transaction nodes adopts a hybrid structure of "linked list + array", which takes into account the advantages of both during operation, thus ensuring performance in the allocation, use, and reclamation of transaction objects.

[0107] After the database starts and all transaction objects are initialized, the number of physical CPU cores on the current server is read. The global transaction list is then split into several smaller linked lists based on the number of CPU cores, i.e., thread-private transaction linked lists. By splitting the transaction object array, locking only needs to be applied within a small scope during the allocation, use, and state changes of transaction objects, avoiding global locking and effectively reducing lock contention and lock waiting. By fully utilizing the host's multi-core capabilities and grouping transaction objects according to the number of physical CPU cores, cross-core access is reduced, further improving access efficiency.

[0108] The transaction object allocation method for relational in-memory databases in this invention adapts memory access efficiency through "scenario-based data structure selection," ensures transaction controllability through "fine-grained state management," reduces conflict detection latency through "deep integration with concurrency control," and balances persistence and recovery speed through "lightweight persistence." Ultimately, it achieves transaction processing capabilities of "high throughput, low latency, and high reliability," greatly reducing memory fragmentation and lock contention issues in the global transaction list. It also efficiently manages memory resources for idle transactions (unenabled transaction objects), avoiding memory leaks, lock contention, and transaction switching overhead.

[0109] This invention also provides a computing device, including: a processor and a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method as described in any of the above embodiments. All implementations in the above method embodiments are applicable to the embodiments of this device and can achieve the same technical effects. Further details are omitted in this embodiment.

[0110] This invention also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method as described in any of the above embodiments. All implementations in the above method embodiments are applicable to the embodiments of this device and can achieve the same technical effects. Further details are omitted in this embodiment.

[0111] It should be noted that in the method of the present invention, the components or steps can obviously be decomposed and / or recombined. These decompositions and / or recombinations should be considered equivalent solutions of the present invention. Furthermore, the steps of performing the above series of processes can naturally be performed in the order described and in chronological order, but are not necessarily required to be performed in chronological order. Some steps can be performed in parallel, overlapping, or independently of each other.

[0112] It should be noted that in the above embodiments, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments described above is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0113] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A transaction object allocation method for a relational in-memory database, characterized in that, include: Get the target maximum number of concurrent transactions; When the relational in-memory database starts, the transaction object memory pool is initialized according to the target maximum transaction concurrency, resulting in an initialized transaction object memory pool. Obtain transaction objects according to the target maximum transaction concurrency, and associate the transaction objects with the initialized transaction object memory pool to obtain a global transaction linked list; The global transaction list is divided according to the obtained number of physical cores to obtain the target thread's private transaction list; The target thread private transaction linked list includes at least a first thread private transaction linked list and a second thread private transaction linked list; Based on the received transaction execution request, the idle transaction objects in the target thread's private transaction list are allocated to obtain the allocation result; Specifically, transaction objects are obtained according to the target maximum transaction concurrency, and these transaction objects are associated with the initialized transaction object memory pool to obtain a global transaction linked list, including: Obtain transaction objects according to the target maximum transaction concurrency; The transaction object is identified by attributes based on the initialized transaction object memory pool to obtain a global transaction linked list; Specifically, the transaction object is identified by attributes based on the initialized transaction object memory pool to obtain a global transaction linked list, including: The transaction object is assigned a transaction identifier according to the initialized transaction object memory pool, resulting in a transaction object with a transaction identifier; The transaction object with the transaction identifier is marked with a status to obtain the transaction object with the status identifier; The transaction objects with status identifiers are associated to obtain a global transaction linked list; Specifically, based on the received transaction execution request, idle transaction objects in the target thread's private transaction list are allocated to obtain the allocation result, including: Receive transaction execution requests; According to the transaction execution request, the first thread private transaction list is locked, and when the first free transaction object is found in the first thread private transaction list, the first free transaction object is marked as being in use, and the first thread private transaction list is unlocked. If no first free transaction object is found in the first thread private transaction list, the second thread private transaction list is locked. If a second free transaction object is found in the second thread private transaction list, the second free transaction object is marked as being in use, and the second thread private transaction list is unlocked. The process of allocating idle transaction objects in the target thread's private transaction list according to the received transaction execution request, and obtaining the allocation result, also includes: If the second free transaction object is not found in the second thread private transaction list, unlock the first thread private transaction list and the second thread private transaction list, and search for the first free transaction object or the second free transaction object when the preset waiting parameter is reached.

2. The method for transaction object allocation for relational in-memory databases as claimed in claim 1, wherein, Get the target maximum transaction concurrency, including: Get the original maximum concurrent transaction count as input by the user; The original maximum transaction concurrency is adjusted according to preset constraints to obtain the target maximum transaction concurrency.

3. The method for allocating transaction objects in a relational in-memory database according to claim 1, characterized in that, When the relational in-memory database starts, it initializes the transaction object memory pool according to the target maximum transaction concurrency, resulting in an initialized transaction object memory pool, including: When the relational in-memory database starts, the memory requirements of the transaction object memory pool are calculated based on the target maximum transaction concurrency. Based on the aforementioned memory requirements, determine the memory region data; The transaction object memory pool is initialized based on the memory region data to obtain the initialized transaction object memory pool.

4. The method for transaction object allocation for relational in-memory databases of claim 1, wherein, The global transaction list is divided based on the obtained number of physical cores to obtain the target thread's private transaction list, including: Obtain the number of physical cores; the number of physical cores refers to the number of physical cores of the central processing unit of the current server. The global transaction list is divided according to the number of physical cores to obtain the target thread private transaction list; the number of the target thread private transaction lists is the same as the number of physical cores.

5. A computing device, comprising: include: A processor, a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method as described in any one of claims 1 to 4.

6. A computer-readable storage medium, characterized in that, The system stores instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 4.

Images