Database deadlock processing method and device and database deadlock processing system

Abstract

The invention relates to a database deadlock processing method, system and device, computer equipment, a storage medium and a computer program product. The method comprises the following steps: receiving first deadlock detection information sent by an upstream node for a target dependency relationship, and determining a period stage of a local node in a deadlock detection period; the target dependency is directed from a first waiting transaction of the upstream node to a first waited transaction of the local node; under the condition that the period phase is a propagation phase, performing blocking deduction on the first waited transaction according to the first deadlock detection information to obtain a blocking deduction result; and when the blocking deduction result represents that the first waited transaction is in a deadlock loop and the first waited transaction meets an unlocking condition, deleting the first waited transaction, and releasing the deadlock loop. By adopting the method, the deadlock processing timeliness can be improved, and the resource consumption in the deadlock processing process can be reduced.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to a database deadlock handling method, system, apparatus, computer equipment, storage medium, and computer program product. Background Technology

[0002] With the widespread application of distributed database systems, the problem of distributed deadlock has become increasingly prominent. Distributed deadlock refers to a circular chain of waits across nodes in a distributed environment, where multiple transactions are waiting for resources held by each other. This type of deadlock involves not only local resources but also remote node resources, making its detection and resolution more complex than in a single-machine environment, and seriously threatening the availability and performance of the database system. Therefore, how to detect and resolve distributed deadlocks in real time and accurately has become a key technical challenge for ensuring the stable operation of distributed databases.

[0003] Traditional distributed databases, such as those based on Extended Clustering (PGXC) architecture, often employ centralized deadlock detection methods. This method provides a detection interface as a plugin, which is manually triggered periodically by the database administrator. During detection, complete lock information needs to be collected from all nodes, a global transaction wait graph is constructed at the central node, and a depth-first search algorithm is used to find cyclic paths. However, this method has significant limitations: first, it cannot detect deadlocks in real time, relying on manual intervention; second, transmitting all lock information consumes substantial network resources; third, as the cluster size increases, the complexity of the global graph surges, causing detection time to increase exponentially; and fourth, there is a risk of false positives, and deadlocks may be missed during network packet loss.

[0004] Therefore, improving the timeliness of deadlock handling and reducing resource consumption during deadlock handling are urgent problems to be solved in the field of distributed databases. Summary of the Invention

[0005] Therefore, it is necessary to provide a database deadlock handling method, system, device, computer equipment, computer-readable storage medium, and computer program product that can improve the timeliness of deadlock handling and reduce the resource consumption during the deadlock handling process, in order to address the above-mentioned technical problems.

[0006] Firstly, this application provides a database deadlock handling method. The method includes:

[0007] Receive the first deadlock detection information sent by the upstream node for the target dependency, and determine the period stage of the deadlock detection cycle in which the local node is located; the target dependency is pointed from the first waiting transaction of the upstream node to the first waiting transaction of the local node.

[0008] When the periodic phase is the propagation phase, a blocking deduction is performed on the first waited transaction based on the first deadlock detection information to obtain the blocking deduction result.

[0009] If the blocking deduction result indicates that the first awaited transaction is in a deadlock loop, and the first awaited transaction meets the unlocking condition, then delete the first awaited transaction and release the deadlock loop.

[0010] Secondly, this application also provides a database deadlock handling system. The system includes multiple data service nodes and auxiliary processes corresponding to each of the data service nodes.

[0011] The data service node is used to manage at least one node transaction;

[0012] The auxiliary process is used to implement the steps of the above method.

[0013] Thirdly, this application also provides a database deadlock handling apparatus, the apparatus comprising:

[0014] The information receiving module is used to receive the first deadlock detection information sent by the upstream node for the target dependency relationship, and to determine the period stage of the local node in the deadlock detection period; the target dependency relationship is pointed from the first waiting transaction of the upstream node to the first waiting transaction of the local node;

[0015] The blocking deduction module is used to perform blocking deduction on the first waited transaction based on the first deadlock detection information when the periodic phase is the propagation phase, and obtain the blocking deduction result.

[0016] The deadlock handling module is used to delete the first awaited transaction and release the deadlock loop when the blocking deduction result indicates that the first awaited transaction is in a deadlock cycle and the first awaited transaction meets the unlocking condition.

[0017] Fourthly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the above-described method.

[0018] Fifthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the steps of the above-described method.

[0019] Sixthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the steps of the above-described method.

[0020] The aforementioned database deadlock methods, systems, devices, computer equipment, storage media, and computer program products, when there is a target dependency relationship where the first waiting transaction of the upstream node points to the first awaited transaction of the local node, will send first deadlock detection information to its corresponding downstream node, i.e., the local node, based on the target dependency relationship. Upon receiving the first deadlock detection information, the local node first determines the cycle stage of the deadlock detection period. If the cycle stage is the propagation stage, it can directly perform blocking deduction on the first awaited transaction based on the first deadlock detection information to obtain the blocking deduction result. If the blocking deduction result indicates that the first awaited transaction is in a deadlock loop, and the first awaited transaction meets the unlocking conditions, the local node can directly delete the first awaited transaction to release the resources held by the first awaited transaction and resolve the deadlock loop. This method does not require setting up a unified node to obtain the dependencies between transactions of all distributed nodes; instead, it achieves real-time detection and resolution of deadlock loops through message passing between upstream and downstream nodes. On the other hand, while eliminating the time required to obtain data on the dependencies between all transaction nodes, each local node only needs to focus on the information exchange between upstream and downstream nodes, effectively reducing the resource consumption during deadlock handling. Attached Figure Description

[0021] Figure 1 This is a block diagram of a database deadlock handling system in one embodiment;

[0022] Figure 2 Here is a block diagram of a database deadlock handling system in another embodiment;

[0023] Figure 3 Here is a block diagram of a database deadlock handling system in another embodiment;

[0024] Figure 4 Here is a block diagram of a database deadlock handling system in another embodiment;

[0025] Figure 5 This is a schematic diagram of the workflow of the polling thread in one embodiment;

[0026] Figure 6 This is a schematic diagram of the workflow of the receiving thread in one embodiment;

[0027] Figure 7 This is a schematic diagram illustrating the workflow of the detection thread in one embodiment;

[0028] Figure 8 This is a flowchart illustrating a database deadlock handling method in one embodiment;

[0029] Figure 9This is a flowchart illustrating a database deadlock handling method in another embodiment;

[0030] Figure 10 This is a flowchart illustrating a database deadlock handling method in another embodiment;

[0031] Figure 11 This is a flowchart illustrating a database deadlock handling method in another embodiment;

[0032] Figure 12 This is a structural block diagram of a database deadlock handling device in one embodiment;

[0033] Figure 13 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0035] The database deadlock handling method provided in this application embodiment can be applied to, for example, Figure 1 The database deadlock handling system 100 shown includes multiple data service nodes 101 and auxiliary processes 102 corresponding to each data service node 101.

[0036] Data Service Node 101 is the collective name for the functional components responsible for core data processing in a distributed database cluster. Taking a distributed database with a PGXC architecture as an example, Data Service Node 101 may include a Coordinator (CN) and DataNodes (DN).

[0037] The CN node provides external interfaces and is responsible for data distribution and query planning. Multiple nodes are geographically equivalent, and each node provides the same database view. Functionally, the CN node only stores global metadata for the system and does not store actual business data. The DN node handles and stores local node-related metadata, and each node also stores shards of business data. Functionally, the DN node is responsible for fulfilling execution requests distributed by the coordinating node.

[0038] Since the CN node is responsible for data distribution and query planning, the auxiliary process 102 can also be considered as a process set up corresponding to the CN node, that is, one auxiliary process is configured for each CN node.

[0039] Among them, the auxiliary process 102, also known as the Forwarder process, is a key component in the distributed deadlock detection system. It is used for message distribution, responsible for communicating with the auxiliary processes of other nodes, collecting the dependencies of transactions managed by the local node, and passing these dependencies for deadlock handling. Deadlock handling includes two processing actions: deadlock detection and deadlock resolution.

[0040] Understandably, the data service node 101 corresponding to the auxiliary process 102 is the local node of the auxiliary process 102.

[0041] In one embodiment, communication between the auxiliary processes 102 can be implemented based on a socket communication mechanism, which allows different computers to exchange data over a network. The socket-based auxiliary processes 102 use an asynchronous communication model, support multi-threaded concurrent request processing, support various operating systems and hardware platforms, and are well-suited for sending, receiving, and propagating deadlock detection messages.

[0042] Specifically, when there exists a target dependency relationship where the first waiting transaction of the upstream node points to the first awaited transaction of the local node, the local node will send a first deadlock detection message to the local node relative to the upstream node of the target dependency relationship, instructing the auxiliary process 102 in the local node to handle the deadlock for the first awaited transaction in the target dependency relationship. After receiving the first deadlock detection message sent by the upstream node for the target dependency relationship, the auxiliary process 102 can first determine the cycle stage of the deadlock detection cycle in which the local node is located. If the cycle stage is the propagation stage, it will perform a blocking deduction on the first awaited transaction based on the first deadlock detection message to obtain the blocking deduction result. If the blocking deduction result indicates that the first awaited transaction is in a deadlock cycle and the first awaited transaction meets the unlocking condition, the auxiliary process 102 will delete the first awaited transaction to release the deadlock cycle.

[0043] The aforementioned database deadlock handling system enables real-time communication between upstream and downstream nodes by setting up corresponding auxiliary processes for each data service node. Upon receiving the first deadlock detection information sent by the upstream node, the auxiliary process can automatically determine the current stage of the cycle and automatically execute the deadlock detection and handling process, effectively improving the real-time performance of database deadlock handling. While eliminating the time required to obtain data on the dependencies between all transaction nodes, each local node only needs to focus on the information interaction between upstream and downstream nodes, effectively reducing the resource consumption during the deadlock handling process.

[0044] In one embodiment, such as Figure 2As shown, the database deadlock handling system 100 also includes a background process 201 configured to correspond to node transactions, and a shared memory 202 configured to correspond to each data service node 101.

[0045] The background process 201 is used to generate new dependencies related to the node transaction based on the transaction resource waiting information of the node transaction, and write the new dependencies into the shared memory 202 that matches the local node. The local node is the data service node 101 used to manage the node transaction.

[0046] Background process 201 can be understood as the dependency generation module in the database deadlock handling system. The generation of dependencies between transactions of each node in the system occurs in the corresponding background process 201.

[0047] A node transaction refers to a data operation unit executed on the corresponding data service node 101, encompassing a complete lifecycle of start, execution, commit, or rollback. It can be understood that one background process 201 corresponds to one node transaction, and one data service node 101 can manage one or more node transactions.

[0048] Among them, the newly added dependencies related to node transactions refer to the dependencies in which a node transaction is either waiting for a transaction or being waited for.

[0049] In one embodiment, the dependencies generated by the background process 201 need to be transmitted to the corresponding auxiliary process 102 for unified dependency management. To enable communication between the background process 201 and the auxiliary process 102, a circular queue can be used in the shared memory 202 to store the dependency information required for distributed deadlock detection. At this time, the background process 201 acts as a producer to write data, and the auxiliary process 102 acts as a consumer to read data.

[0050] Among them, the transaction resource waiting information is the lock waiting information of the transaction node. The background process 201 can obtain the lock waiting information of the transaction node when the node transaction is in a blocked state, analyze the node process state and lock state based on the lock waiting information, and generate new dependencies related to the node transaction.

[0051] Specifically, when the background process 201 detects that the corresponding node transaction is in a blocked state, it can obtain the transaction resource waiting information of the node transaction, generate new dependencies related to the node transaction based on the transaction resource waiting information, and write the new dependencies into the shared memory 202 that matches the local node.

[0052] In the above embodiments, by setting up an independent background process for each node transaction in the database deadlock handling system and configuring dedicated shared memory for each data service node, distributed parallel processing of deadlock detection is realized, which significantly improves the real-time performance of the system. At the same time, the isolation between processes and memory enhances the reliability and scalability of the system.

[0053] In one embodiment, the background process is also used to respond to resource release events for node transactions by removing passive dependencies associated with the node transaction from shared memory.

[0054] Among them, resource release events refer to actions that trigger the release of transaction resources within a node transaction. Passive dependencies related to a node transaction refer to dependencies in which the node transaction is waiting for a transaction.

[0055] Specifically, in addition to dependency generation, the background process can also maintain a dependency queue. When a resource release event for a node transaction is triggered, the background process can respond to the resource release event in real time and remove the passive dependencies related to the node transaction from the shared memory.

[0056] In one embodiment, when a background process enters the lock request queue but fails to acquire the lock, a dependency between this process and the lock holder process is created; when the background process acquires the lock, the dependency between this process and the lock holder process is deleted.

[0057] In the above embodiments, the background process can manage and maintain the dependency queue in the shared memory, so that each dependency can be processed in a timely manner according to the time order, effectively preventing dependency loss or handling conflicts. By providing a stable and continuous data input stream to the auxiliary process, the accuracy and efficiency of deadlock handling can be significantly improved.

[0058] In one embodiment, if a background process has an unlocked write location in shared memory, it obtains the flag information of the historical dependencies stored in the write location. If the flag information indicates that the historical dependency is invalid, it writes the new dependency at the write location.

[0059] In order to isolate multiple processes reading and writing from shared memory, and to ensure that reading and writing are not mutually exclusive, a lightweight read-write lock can be set for each storage location in shared memory. When using a lightweight lock, it is only used to obtain location information, and no lock is added when writing or reading data. Since this lightweight lock will occupy running memory, locking when operating data will waste the performance of system running memory. However, after implementing mutual exclusion for multiple processes reading and writing at the same time, there is no need to add locks when operating data, which greatly speeds up the read and write speed.

[0060] Specifically, when a background process needs to write a new dependency into shared memory, it first needs to determine if there is an unlocked write location in shared memory. If so, it means the write location is not occupied. The background process will then obtain the flag information of the historical dependencies already stored in the write location and determine whether the historical dependency is invalid based on the flag information. If it is invalid, it is considered that the historical dependency at the write location can be overwritten, and the background process writes the new dependency at the write location. If the historical dependency is valid, it means that the historical dependency is still waiting to be read and cannot be directly overwritten. Therefore, the background process can return to the step of determining whether there is an unlocked write location in shared memory and re-determine the write location from shared memory.

[0061] In one embodiment, the background process can determine whether historical dependency data is valid based on the flag information. Since the background process usually uses a fixed block size when reading data, memory alignment is required when writing dependencies to prevent incorrect flag information from being read due to the lack of memory alignment, which could lead to a misjudgment of the valid status.

[0062] In one embodiment, the background process can align the head node in the shared memory circular queue to an integer multiple of the block size in bytes.

[0063] In one embodiment, the step of allocating space in shared memory may include:

[0064] First, request a memory segment through the operating system.

[0065] Second, use global variables to record the location of shared memory.

[0066] Third, a lock is created for global variable allocation. The most important function of this interface is to complete the initialization of the shared memory spinlock. The purpose of this lock is to ensure that the allocation operation of shared memory is mutually exclusive. In other words, from this point on, the allocation of shared memory can begin.

[0067] Fourth, create a globally usable lock structure.

[0068] Fifth, create a hash table in the shared memory. The hash table is used to record the structure of controls that have already requested shared memory, enabling fast retrieval while avoiding duplicate requests.

[0069] After completing the first five steps above, the basic initialization of the shared memory data structure is finished. Then, shared memory space can be allocated according to specific needs. Generally, shared memory allocation involves two steps: first, calculating the required space size; and second, actually allocating the space. A diagram illustrating circular queue space allocation can be seen as follows... Figure 3 As shown.

[0070] In one embodiment, such as Figure 4 As shown, a database deadlock handling system is provided. The system includes multiple data service nodes 101, auxiliary processes 102 corresponding to each data service node 101, background processes 201 corresponding to node transactions, and shared memory 202 corresponding to each data service node.

[0071] The database deadlock handling system can be a Distributed Dependency Spread (DDS) system. The auxiliary process 102 can include three dedicated DDS threads: a polling thread 401, a receiving thread 402, and a detecting thread 403. Each data service node 101 can include a CN node 404 and a DN node 405.

[0072] Polling thread 401 interacts with the shared memory circular queue, acting as a consumer that continuously consumes messages produced by the background process. It packages and sends different types of messages based on their message types.

[0073] Specifically, polling thread 401 is responsible for polling the dependency queue. Its workflow can be as follows: Figure 5 As shown, in each loop, the shared memory array is traversed first. If a signal is found, it is saved to a local variable, and the contents of the shared memory are cleared. Then, based on the signal type, it is determined whether it is a newly added dependency. If it is, the new dependency is saved to a local array; if it is a deleted dependency, the dependency is first deleted from the local array, then created and a downstream update message is sent. After traversing the shared memory array, the local array is traversed. The local array records all dependencies existing on all local nodes; for each dependency, a broadcast message is created and sent.

[0074] Polling thread 401 is a crucial link in the database deadlock handling system. First, it interacts with background process 201 as a consumer, retrieving dependency information from shared memory 202. This data is fundamental for deadlock detection, so the polling thread must obtain it promptly and accurately. Then, it collaborates with detection thread 403, acting as a producer to package and send different types of DDS messages. Detection thread 403 handles the specific deadlock detection logic. In this way, polling thread 401 and detection thread 403 can jointly complete the deadlock handling process.

[0075] The receiving thread 402 can be used to receive DDS messages and save them to a message queue. Specifically, the workflow of the receiving thread 402 can be as follows: Figure 6 As shown, receiving thread 402 mainly reads DDS messages from other nodes from the communication storage file, parses them, and saves them to the message queue of the detection thread 403 on the local node. The sleep time of receiving thread 402 is short, so it can be understood that once a message is received, it can be immediately saved to the message queue.

[0076] In one embodiment, the DDS messages that the receiving thread 402 can receive mainly include the following categories: First, broadcast messages, sent by the polling thread 401 to the detection thread 403, used to report newly added transaction dependency pairs. Second, deadlock detection algorithm messages, which can be passed between each CN node 404 for deadlock detection algorithm deduction and cycle detection. Third, downstream node update messages, sent by the polling thread 401 to the detection thread 403, used to report deleted transaction dependency pairs. Fourth, transaction abort messages, sent by the CN node that started the transaction to other nodes to clean up residual distributed transactions.

[0077] Among them, the detection thread 403 can perform DDS message processing according to the message type, such as updating the detection node, i.e., messages within the deadlock detection node, executing the deadlock detection algorithm, and creating the detection node.

[0078] Specifically, detection thread 403 can continuously scan the message queue. If a new message is received, it determines the message type and performs corresponding processing based on the message type. The workflow of detection thread 403 can be as follows: Figure 7As shown, if the message type is a broadcast message, it indicates that a detection node may need to be started, using a hash table in the detection node to store all (node ​​transaction, detection node) key-value pairs. If it is a deadlock detection algorithm message, detection thread 403 first checks if the transaction exists in the detection node's hash table. If it does not exist, it skips the process; if it exists, it executes the DDS algorithm function. If the DDS algorithm function returns true after execution, it indicates a deadlock has been detected, and the transaction is killed. If it is a downstream node update message, the downstream node information of the current node is updated. If there are no downstream nodes in the downstream node list managed by the current detection node, the current detection node is deleted, and the hash table is updated. If it is a transaction abort message, detection thread 403 can abort the message sending process because the sending process is detected by CN node 404 as a residual of a distributed transaction.

[0079] After completing the above steps, detection thread 403 will traverse the list of downstream nodes of its own detection node and send deadlock detection information to these downstream nodes respectively.

[0080] In one embodiment, the detection thread 403 also detects the node survival time of all its own detection nodes. If the node survival time exceeds a preset time threshold, the detection node can be deleted.

[0081] Understandably, the detection node 403 is the thread that executes the DDS algorithm. It is responsible for handling the received messages and executing the algorithm. Depending on the message type, the detection node 403 will enter different processing logic, including creating a detection node, updating the downstream node information of the local node, and executing the DDS algorithm. It works in conjunction with the polling thread 401 to complete the final step of deadlock detection.

[0082] Based on the same inventive concept, in one embodiment, such as Figure 8 As shown, a database deadlock handling method is provided, which can be applied to... Figure 1 Taking the auxiliary process 102 as an example, the following steps are included:

[0083] S802, receive the first deadlock detection information sent by the upstream node for the target dependency relationship, and determine the cycle stage in which the local node is in the deadlock detection cycle.

[0084] Among them, the dependency relationship can be used to characterize the resource dependency relationship between transaction dependency pairs. When a waiting relationship occurs between node transactions, a transaction dependency pair will be generated. A transaction dependency pair includes a waiting transaction and a waiting transaction. The waiting transaction holds the resources required by the waiting transaction, or in other words, the waiting transaction holds the lock that the waiting transaction is waiting for.

[0085] The target dependency relationship points from the first waiting transaction on the upstream node to the first waiting transaction on the local node. The upstream node, in the target dependency relationship, refers to the predecessor node that points to the local node; that is, the data service node where the waiting transaction for the local node resides. The local node is the data service node currently performing deadlock detection processing, responsible for receiving and processing detection information from the upstream node.

[0086] The first deadlock detection information is detection data received from the upstream node, which can be used to identify the first waiting transaction on the upstream node. For example, the first deadlock detection information may include the detection sequence value, label value, creation timestamp, and other information of the first waiting transaction. Through the first deadlock detection information, the local node can know the core detection parameters required for deadlock handling of the waiting transaction.

[0087] The deadlock detection period, or DDS period, is a fixed time window for the distributed deadlock detection algorithm to run. It typically consists of two phases: a growth phase and a propagation phase, used to systematically execute the deadlock detection process. Understandably, the way a local node processes deadlock detection information differs depending on the phase it is in.

[0088] The growth phase is the core processing stage in the distributed deadlock detection algorithm. During this stage, deadlock risks are identified and propagated through a specific numerical propagation mechanism. The propagation phase is the crucial convergence stage in the distributed deadlock detection algorithm. During this stage, deadlock cycles are confirmed and sacrificed transactions are identified through numerical unification and label propagation.

[0089] Specifically, the auxiliary processes of the local node and the auxiliary processes of the upstream node can communicate. After the upstream node discovers the existence of a target dependency, it can determine the data service node where the waiting transaction is located, i.e., the local node, based on the direction of the target dependency. Then, it sends the first deadlock detection information for the target dependency. When the local node receives the first deadlock detection information sent by the upstream node, it will first determine the cycle stage in which the local node is in the deadlock detection cycle. Because the cycle stage is different, the corresponding processing method is also different.

[0090] S804, when the periodic phase is the propagation phase, performs a blocking deduction on the first waiting transaction based on the first deadlock detection information to obtain the blocking deduction result.

[0091] Among them, blocking deduction refers to the deadlock detection algorithm deduction process in the propagation phase, that is, in the propagation phase of distributed deadlock detection, the calculation process of uniformly converging the transaction state and propagating the label according to a specific algorithm function.

[0092] The blocking deduction result is the state output obtained after the deadlock detection algorithm is deduced during the propagation phase. It can be understood as the globally consistent state set formed after complete state convergence. Through the blocking deduction result, the deadlock detection result of the first waited transaction and the deadlock handling method can be determined.

[0093] Specifically, when the auxiliary process determines that the local node is in the propagation phase of the cycle, it can perform a blocking deduction on the first waiting transaction based on the first deadlock detection information and obtain the blocking deduction result.

[0094] In one embodiment, the auxiliary process can call a pre-set blocking simulation model. It only needs to input the first deadlock detection information and the transaction information of the first waited transaction into the blocking simulation model to obtain the blocking simulation result.

[0095] S806, if the blocking simulation results indicate that the first awaited transaction is in a deadlock loop, and the first awaited transaction meets the unlocking conditions, delete the first awaited transaction to release the deadlock loop.

[0096] Among them, deadlock loop can also be called deadlock cycle. When two or more node transactions hold the resources required by each other, causing these node transactions to be unable to continue to execute, they will enter a blocking state that cannot be resolved. The necessary conditions for the formation of deadlock loop can include mutual exclusion, hold and wait, no preemption, and circular wait.

[0097] The unlock condition is a preset condition used to determine whether the deadlock loop needs to be unlocked by deleting the first waited transaction.

[0098] In one embodiment, if the first awaited transaction meets the unlock condition, it can be assumed that deleting the first awaited transaction will resolve the deadlock loop. If the first awaited transaction does not meet the unlock condition, it means that although the first awaited transaction is in a deadlock loop, deleting the first awaited transaction cannot resolve the deadlock loop.

[0099] In one embodiment, if the first awaited transaction meets the unlocking condition, deleting the first awaited transaction can be considered the best choice to resolve the deadlock loop. If the first awaited transaction does not meet the unlocking condition, it means that although deleting the first awaited transaction can resolve the deadlock loop, it is not the best unlocking choice, and deleting the first awaited transaction may result in the transaction execution result not meeting the actual requirements.

[0100] Specifically, if the blocking simulation result indicates that the first waited transaction is in a deadlock loop and the first waited transaction meets the unlocking conditions, the auxiliary process can delete the first waited transaction. This is done by removing the key node in the deadlock loop, thereby breaking the circular waiting chain between transactions and unlocking the deadlock loop.

[0101] In the above embodiments, when there is a target dependency relationship between the first waiting transaction of the upstream node and the first awaited transaction of the local node, the upstream node will send the first deadlock detection information to its corresponding downstream node, i.e., the local node, for the target dependency relationship. After receiving the first deadlock detection information, the local node first determines the cycle stage in which the local node is in the deadlock detection cycle. If the cycle stage is the propagation stage, it can directly perform blocking inference on the first awaited transaction based on the first deadlock detection information to obtain the blocking inference result. If the blocking inference result indicates that the first awaited transaction is in a deadlock loop, and the first awaited transaction meets the unlocking condition, the local node can directly delete the first awaited transaction to release the resources held by the first awaited transaction and resolve the deadlock loop. The above method does not require setting up a unified node to obtain the dependencies between all distributed node transactions. Instead, it achieves real-time detection and resolution of deadlock loops through message passing between upstream and downstream nodes. On the other hand, while saving the data acquisition time for obtaining the dependencies between all transaction nodes, each local node only needs to focus on the information interaction between upstream and downstream nodes, effectively reducing the resource consumption during the deadlock handling process.

[0102] In one embodiment, the first deadlock detection information includes a first public label of the first waiting transaction and a first detection sequence value. For example... Figure 9 As shown, database deadlock handling methods also include:

[0103] S902, compare the first detection sequence value with the second detection sequence value of the first awaited transaction, update the second detection sequence value with the maximum sequence value, and obtain the target second detection sequence value.

[0104] The first detection sequence value is the detection sequence value of the first waiting transaction, and the second detection sequence value is the detection sequence value of the first transaction being waited for. The detection sequence value is an integer, updated according to the algorithm rules during the growth and propagation phases, and is used for deadlock detection deduction.

[0105] Specifically, the auxiliary process can compare the first detection sequence value of the first waiting transaction with the second detection sequence value of the first awaited transaction, determine the maximum sequence value between the first and second detection sequence values ​​as the target second detection sequence value, and complete the update of the second detection sequence value.

[0106] S904, if the target second detection sequence value is equal to the first detection sequence value, the second public label is updated using the largest public label among the first public label and the second public label of the first waited transaction, to obtain the target second public label.

[0107] In this context, the public label refers to the label propagated between transactions during the propagation phase of the DDS algorithm. The public label can consist of a global transaction ID and a transaction creation timestamp. During propagation, the public label changes to identify the transaction's priority. The first public label refers to the public label value of the first transaction being waited for. The second public label refers to the public label of the first waiting transaction.

[0108] Specifically, the auxiliary process can compare the target second detection sequence value with the first detection sequence value. If the target second detection sequence value is equal to the first detection sequence value, the first public label is compared with the second public label. The largest public label is selected from the first public label and the second public label as the target second public label, thus completing the update of the second public label.

[0109] S906, if the target second detection sequence value is equal to the first detection sequence value and the first public label is equal to the target second public label when the propagation phase ends, then it is determined that the first waited transaction is in a deadlock loop.

[0110] Specifically, after the propagation phase ends, the auxiliary process can compare the target second detection sequence value with the first detection sequence value and compare the first public label with the target second public label. If the target second detection sequence value is equal to the first detection sequence value and the first public label is equal to the target second public label, it indicates that the first waited transaction is in a deadlock loop.

[0111] In the above embodiments, the auxiliary process can quickly determine whether the first waiting transaction is in a deadlock loop by observing the changes in information such as label sequence value, public label, and private label during the blocking simulation process, which effectively improves the efficiency and accuracy of deadlock detection.

[0112] In one embodiment, if the first awaited transaction is in a deadlock loop and is the lowest priority transaction in the deadlock loop, it is determined that the first awaited transaction meets the unlocking condition.

[0113] Among them, the lowest priority transaction refers to the transaction instance with the lowest execution priority in the deadlock loop. The transaction priority is usually determined by the timestamp of the transaction creation. For example, the later the creation time, the lower the corresponding transaction priority.

[0114] Specifically, if the auxiliary process determines that the first awaited transaction is in a deadlock loop, it can determine the priority of the first awaited transaction to see if it is the lowest priority transaction in the deadlock loop. If so, it can determine that the first awaited transaction meets the unlocking conditions and the deadlock loop can be resolved by deleting the first awaited transaction.

[0115] In the above embodiments, if the auxiliary process determines that the first waited transaction is the lowest priority transaction in the deadlock loop, it can select the lowest priority transaction as a sacrifice to minimize the unlocking cost of breaking the deadlock loop.

[0116] In one embodiment, the database deadlock handling method further includes: if the blocking deduction result indicates that the first awaited transaction is in a deadlock loop, comparing the private label of the first awaited transaction with a target second public label. If the private label of the awaited transaction matches the target second public label, then the first awaited transaction is determined to be the lowest priority transaction in the deadlock loop.

[0117] The private label of the awaited transaction is an inherent identifier used to uniquely identify the first awaited transaction. It can consist of a global transaction ID and a transaction creation timestamp, and is determined at the time of transaction creation and will not change as blocking propagation occurs. In contrast to the public label, the public label of a transaction on the same node is initialized to equal its corresponding private label. The difference is that the private label, once determined, will not change, while the public label can change as dependencies propagate.

[0118] Specifically, when the blocking simulation result indicates that the first awaited transaction is in a deadlock loop, the auxiliary process can compare the private label of the awaited transaction with the target second public label, since the public label can be used to represent the lowest priority transaction in the deadlock loop. If the two match, the first awaited transaction can be considered to be the lowest priority transaction in the deadlock loop.

[0119] In the above embodiments, by comparing the target second public label with the private label of the waited transaction, it is possible to quickly determine whether the waited transaction is the lowest priority transaction in the deadlock loop, thereby improving the accuracy and efficiency of transaction priority judgment and providing a data foundation for subsequent deadlock resolution.

[0120] In one embodiment, the database deadlock handling method further includes: when the periodic phase is an increasing phase, incrementing the first detection sequence value using a preset incremental parameter to update the first detection sequence value; and updating the second detection sequence value using the updated first detection sequence value and the maximum detection sequence value among the second detection sequence values.

[0121] The preset increment parameter is a processing parameter used to increment the value of the first detection sequence during the growth phase. Incremental processing refers to the process of incrementally calculating the detection sequence value. Understandably, the preset increment parameter can be a fixed increment constant configured for the algorithm, typically an integer of 1.

[0122] Specifically, when the auxiliary process is in the growth phase of the cycle, it can use a pre-configured preset incremental parameter to increment the value of the first detection sequence, update the value of the first detection sequence, and then compare the updated value of the first detection sequence with the value of the second detection sequence. The maximum value of the first detection sequence and the value of the second detection sequence are selected as the value of the second detection sequence, and the original value of the second detection sequence is updated.

[0123] In the above embodiments, by performing amplification processing on the first detection sequence value during the growth phase, the deadlock risk can be quantified, propagated, and amplified, providing a reliable numerical basis for subsequent deadlock detection.

[0124] In one embodiment, such as Figure 10 As shown, database deadlock handling methods also include:

[0125] S1002, if there are new dependencies related to the local node in the shared memory corresponding to the local node, obtain the mapping relationship between each detection node and each node transaction in the local node.

[0126] New dependencies are newly discovered dependencies related to the local node. A new dependency can originate from a second waiting transaction on the local node, pointing to a second waiting transaction on a downstream node. The downstream node is the data service node where the transaction in the new dependency is located, relative to the local node and positioned while waiting for the resource.

[0127] The detection node can be considered the core data structure in the deadlock detection algorithm. Its role is to create a virtual proxy entity for each node transaction in the detection system, representing the real node transaction in algorithm deduction and state tracking during the deadlock detection process. Understandably, since each detection node corresponds to a node transaction, there is a one-to-one mapping relationship between each node transaction on the local node and each detection node.

[0128] Specifically, the auxiliary process can act as a consumer, reading relevant dependency information from the shared memory corresponding to the local node. When traversing the shared memory, if a new dependency relationship related to the local node is found, that is, the dependency relationship from the second waiting transaction in the local node to the second waiting transaction in the downstream node, then the mapping relationship between each detection node and each node transaction in the local node is obtained.

[0129] In one embodiment, the mapping relationship between each detection node and each node transaction in the local node can be maintained by a hash table. When a detection node is created for a node transaction, the auxiliary process will record the correspondence between the detection node and its corresponding node transaction in the hash table.

[0130] S1004. If, based on the mapping relationship, it is determined that there is no detection node matching the second waiting transaction on the local node, then a blocking detection node corresponding to the second waiting transaction is created based on the waiting transaction information of the second waiting transaction.

[0131] The congestion detection node is used to record the pending transactions that are dependent on the second pending transaction. It is understood that the pending transactions that are dependent on the second pending transaction can be single or multiple. In the case of multiple pending transactions, the congestion detection node will record a list of downstream nodes for the second pending transaction, where each downstream node in the list refers to the data service node to which the corresponding pending transaction belongs.

[0132] Among them, the waiting transaction information is information data used to characterize the transaction details of the second waiting transaction. For example, the waiting transaction information may include detailed information such as transaction ID, creation timestamp, and waiting resources.

[0133] Specifically, the auxiliary process can look up the mapping relationship based on the second waiting transaction to determine whether there is a detection node in the local node that matches the second waiting transaction. If not, the auxiliary process can create a blocking node corresponding to the second waiting transaction based on the transaction information of the second waiting transaction.

[0134] S1006, Generate second deadlock detection information for newly added dependencies based on waiting transaction information, and send the second deadlock detection information to downstream nodes.

[0135] Specifically, after creating a corresponding blocking detection node for the second waiting transaction, the auxiliary process can generate second deadlock detection information for the newly added dependency based on the waiting transaction information, and send the second deadlock detection information to the downstream node so as to instruct the downstream node to perform deadlock detection and processing on the second waiting transaction based on the second deadlock detection information.

[0136] In the above embodiments, the auxiliary process can capture new dependency information related to the local node in real time, and by creating a corresponding detection node for each second waiting transaction, it can reduce the risk of deadlock failure due to missing detection nodes.

[0137] In one embodiment, the database deadlock handling method further includes: obtaining the node liveness duration of the blocking detection node in real time. If the node liveness duration exceeds a preset duration threshold, the blocking detection node is deleted.

[0138] Among them, node survival time is the length of time that a congestion detection node has existed continuously since its creation, reflecting the life cycle of the congestion detection node in the system.

[0139] The preset duration threshold is a pre-configured time limit parameter used to determine whether a node needs to be cleaned up due to timeout. Understandably, the preset duration threshold can be determined by the designer based on experimental or empirical values; for example, it could be set to 5 seconds.

[0140] Specifically, the auxiliary process can obtain the node survival time of the blocking detection node in real time and compare the node survival time with a preset time threshold. If the node survival time exceeds the preset time threshold, it is determined that the blocking detection node has timed out, which may be due to a system failure. In order to avoid frequently sending DDS messages to downstream nodes, the auxiliary process can delete the blocking detection node.

[0141] In one embodiment, a database deadlock handling method is provided, which is applied to, for example... Figure 4 The database deadlock handling system illustrated here describes its workflow, which mainly includes dependency generation, message packaging, message propagation, algorithm deduction, and transaction abort. When a background process is blocked waiting for a lock, lock waiting can be detected. The background process then obtains the lock waiting information, generates a transaction dependency pair (e.g., a->b represents transaction a waiting for transaction b, where transaction b is a downstream node of transaction a), and passes this dependency to the auxiliary process. The auxiliary process generates a detection node for each transaction, and each detection node records its own list of direct downstream transactions. For each dependency, the auxiliary process packages a deadlock detection message and sends it to the CN node where the downstream transaction resides. The message includes information such as the label value needed for deadlock detection algorithm deduction. Each time a downstream transaction receives such a deadlock detection message, it performs a deadlock detection algorithm deduction. The deadlock detection algorithm consists of two phases: a growth phase and a propagation phase. The algorithm deduction of one phase is selected and executed according to time. If the propagation phase is selected, a deadlock determination will be made based on the propagation results after the deduction is completed. If certain determination conditions are met, it will be considered that a deadlock has been detected, and the deadlock will be resolved by suspending transactions.

[0142] like Figure 11 As shown, when the auxiliary process performs database deadlock handling, the database deadlock handling method may include the following steps:

[0143] S1101, if there are new dependencies related to the local node in the shared memory corresponding to the local node, obtain the mapping relationship between each detection node and each node transaction in the local node.

[0144] Specifically, the polling thread in the auxiliary process is responsible for polling and traversing the shared memory. If it determines that there are new dependencies related to the local node in the shared memory, it can create and send broadcast messages for the new dependencies. The detection thread is responsible for obtaining the mapping relationship between each detection node and each node transaction in the local node.

[0145] S1102, if it is determined from the mapping relationship that there is no detection node matching the second waiting transaction on the local node, then a blocking detection node corresponding to the second waiting transaction is created based on the waiting transaction information of the second waiting transaction.

[0146] Specifically, if the detection thread determines, based on the mapping relationship, that there is no detection node on the local node that matches the second waiting transaction, it can create a blocking detection node corresponding to the second waiting transaction based on the waiting transaction information of the second waiting transaction.

[0147] S1103, Generate second deadlock detection information for newly added dependencies based on waiting transaction information, and send the second deadlock detection information to downstream nodes.

[0148] Specifically, the detection thread can generate a second deadlock detection message for the newly added dependency based on the waiting transaction information, and then package the second deadlock detection message and send it to the downstream node.

[0149] S1104, Receive the first deadlock detection information sent by the upstream node for the target dependency relationship, and determine the cycle stage in which the local node is in the deadlock detection cycle.

[0150] Specifically, the receiving thread in the auxiliary process can receive the first deadlock detection information sent by the upstream node for the target dependency relationship, and the detection thread calculates the period stage of the local node in the deadlock detection period based on the current timestamp of the local node.

[0151] In one embodiment, the growth phase may be defined as lasting 0.4 seconds and the propagation phase as lasting 1 second.

[0152] S1105, when the periodic phase is the growth phase, the first detection sequence value is incremented using a preset incremental parameter to update the first detection sequence value.

[0153] The first deadlock detection information includes the first public label and the first detection sequence value of the first waiting transaction.

[0154] Specifically, the detection thread can use a deadlock detection algorithm to perform deadlock detection on the first waiting transaction. If the periodic phase is determined to be an increasing phase, the first detection sequence value is incremented using a preset incremental parameter to update the first detection sequence value.

[0155] S1106, Update the second detection sequence value using the updated first detection sequence value and the maximum detection sequence value among the second detection sequence values.

[0156] S1107, when the periodic phase is the propagation phase, the first detection sequence value and the second detection sequence value of the first waited transaction are compared, and the second detection sequence value is updated using the maximum sequence value to obtain the target second detection sequence value.

[0157] S1108, if the target second detection sequence value is equal to the first detection sequence value, the second public label is updated using the largest public label among the first public label and the second public label of the first waited transaction to obtain the target second public label.

[0158] S1109, if the target second detection sequence value is equal to the first detection sequence value and the first public label is equal to the target second public label when the propagation phase ends, then it is determined that the first waited transaction is in a deadlock loop.

[0159] S1110, compare the private label of the first awaited transaction with the target second public label.

[0160] S1111 If the private label of the waited transaction matches the target second public label, then the first waited transaction is determined to be the lowest priority transaction in the deadlock loop.

[0161] S1112, delete the first pending transaction and break the deadlock loop.

[0162] In one embodiment, a deadlock determination is performed after the propagation phase, and the determination criteria are as follows:

[0163] The detection sequence value of transaction a == the detection sequence value of transaction b && the public label of transaction a == the public label of transaction b && the public label of transaction b == the private label of transaction b.

[0164] If the judgment condition is met, it can be assumed that transaction b, corresponding to the current detection node DDSNode, is in a deadlock loop and is the transaction with the lowest priority in the deadlock loop. At this time, the deadlock loop can be resolved by sending a transaction abort signal on the CN node to which transaction b belongs.

[0165] The database deadlock handling method and system described in the above embodiments no longer require a unified node to obtain the dependencies between transactions in all distributed nodes during deadlock handling. Instead, through the cooperation between processes, shared memory, and threads, the messages needed to resolve the deadlock are continuously transmitted, thereby quickly and efficiently detecting and resolving deadlocks, ensuring the safe and stable operation of the distributed database system. The system can solve the problems of currently common centralized algorithms, namely, it can detect and resolve deadlocks in real time without requiring manual, timed invocation. Dependencies are generated locally when the background process is stuck, and only dependencies are propagated, resulting in low network resource consumption. Information for each edge can be sent and processed in parallel, and dependencies outside the deadlock loop will not significantly affect dependencies inside the deadlock loop. Therefore, time performance and efficiency are greatly improved. Furthermore, there are no false deadlock detections, and the system is insensitive to network packet loss, accurately finding and resolving deadlocks even under high packet loss rates.

[0166] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0167] Based on the same inventive concept, this application also provides a database deadlock handling apparatus for implementing the database deadlock handling method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more embodiments of the database deadlock handling apparatus provided below can be found in the limitations of the database deadlock handling method described above, and will not be repeated here.

[0168] In one embodiment, such as Figure 12 As shown, a database deadlock handling device 1200 is provided, including: an information receiving module 1201, a blocking deduction module 1202, and a deadlock handling module 1203, wherein:

[0169] The information receiving module 1201 is used to receive the first deadlock detection information sent by the upstream node for the target dependency relationship, and to determine the period stage of the local node in the deadlock detection period; the target dependency relationship is pointed from the first waiting transaction of the upstream node to the first waiting transaction of the local node;

[0170] The blocking deduction module 1202 is used to perform blocking deduction on the first waiting transaction based on the first deadlock detection information when the periodic phase is the propagation phase, and obtain the blocking deduction result.

[0171] The deadlock handling module 1203 is used to delete the first waited transaction and release the deadlock loop when the blocking deduction result indicates that the first waited transaction is in a deadlock cycle and the first waited transaction meets the unlocking condition.

[0172] In one embodiment, the first deadlock detection information includes a first public label of the first waiting transaction and a first detection sequence value. The database deadlock handling apparatus 1200 includes:

[0173] The detection sequence value update module is used to compare the first detection sequence value with the second detection sequence value of the first awaited transaction, update the second detection sequence value using the maximum sequence value, and obtain the target second detection sequence value.

[0174] The public label update module is used to update the second public label by using the largest public label among the first public label and the second public label of the first awaited transaction, when the target second detection sequence value is equal to the first detection sequence value, so as to obtain the target second public label.

[0175] The deadlock loop detection module is used to determine that the first waited transaction is in a deadlock loop if, at the end of the propagation phase, the target second detection sequence value is equal to the first detection sequence value and the first public label is equal to the target second public label.

[0176] In one embodiment, the deadlock handling module 1203 is configured to: determine that the first awaited transaction meets the unlocking conditions when the first awaited transaction is in a deadlock loop and is the lowest priority transaction in the deadlock loop.

[0177] In one embodiment, the deadlock handling module 1203 is configured to: when the blocking deduction result indicates that the first awaited transaction is in a deadlock loop, compare the private label of the awaited transaction of the first awaited transaction with the target second public label; if the private label of the awaited transaction matches the target second public label, then determine that the first awaited transaction is the lowest priority transaction in the deadlock loop.

[0178] In one embodiment, the database deadlock handling apparatus 1200 includes:

[0179] The growth projection module is used to update the first detection sequence value by adding a value using a preset incremental parameter when the cycle phase is a growth phase; and to update the second detection sequence value using the updated first detection sequence value and the maximum detection sequence value among the second detection sequence values.

[0180] In one embodiment, the database deadlock handling apparatus 1200 includes:

[0181] The mapping relationship acquisition module is used to acquire the mapping relationship between each detection node and each node transaction in the local node when there is a new dependency relationship related to the local node in the shared memory corresponding to the local node; the new dependency relationship is pointed from the second waiting transaction in the local node to the second waiting transaction of the downstream node.

[0182] The blocking node creation module is used to create a blocking detection node corresponding to the second waiting transaction if it is determined from the mapping relationship that there is no detection node matching the second waiting transaction on the local node. The blocking detection node is used to record the waiting transactions that have a dependency relationship with the second waiting transaction.

[0183] The information sending module is used to generate second deadlock detection information for newly added dependencies based on waiting transaction information, and send the second deadlock detection information to downstream nodes.

[0184] In one embodiment, the database deadlock handling apparatus 1200 includes:

[0185] The timeout detection module is used to obtain the node survival time of the blocking detection node in real time; if the node survival time exceeds the preset time threshold, the blocking detection node is deleted.

[0186] The modules in the aforementioned database deadlock handling device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0187] In one embodiment, a computer device is provided, which may be a server equipped with a database deadlock handling system, and its internal structure diagram may be as follows. Figure 13 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data related to database deadlock handling methods. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer program implements a database deadlock handling method.

[0188] Those skilled in the art will understand that Figure 13 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0189] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the specific embodiment of the database deadlock handling method described above.

[0190] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the specific implementation steps of the database deadlock handling method described above.

[0191] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the specific embodiment of the database deadlock handling method described above.

[0192] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the acquisition, storage, processing, and transmission of the data all comply with relevant laws and regulations.

[0193] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0194] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0195] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A database deadlock handling method, characterized in that, The method includes: Receive the first deadlock detection information sent by the upstream node for the target dependency, and determine the period stage of the deadlock detection cycle in which the local node is located; the target dependency is pointed from the first waiting transaction of the upstream node to the first waiting transaction of the local node. When the periodic phase is the propagation phase, a blocking deduction is performed on the first waited transaction based on the first deadlock detection information to obtain the blocking deduction result. If the blocking deduction result indicates that the first awaited transaction is in a deadlock loop, and the first awaited transaction meets the unlocking condition, then delete the first awaited transaction and release the deadlock loop.

2. The method according to claim 1, characterized in that, The first deadlock detection information includes the first public label and the first detection sequence value of the first waiting transaction; the method further includes: The first detection sequence value is compared with the second detection sequence value of the first waited transaction, and the second detection sequence value is updated using the maximum sequence value to obtain the target second detection sequence value; If the target second detection sequence value is equal to the first detection sequence value, the second public label is updated using the largest public label among the first public label and the second public label of the first waited transaction to obtain the target second public label; If, at the end of the propagation phase, the target second detection sequence value is equal to the first detection sequence value, and the first public label is equal to the target second public label, then the first waited transaction is determined to be in a deadlock loop.

3. The method according to claim 2, characterized in that, The method further includes: If the first awaited transaction is in a deadlock loop and is the lowest priority transaction in the deadlock loop, then the first awaited transaction is determined to meet the unlocking condition.

4. The method according to claim 3, characterized in that, The method further includes: If the blocking deduction result indicates that the first awaited transaction is in a deadlock loop, the private label of the first awaited transaction is compared with the target second public label. If the private label of the awaited transaction matches the target second public label, then the first awaited transaction is determined to be the lowest priority transaction in the deadlock loop.

5. The method according to claim 4, characterized in that, The method further includes: When the periodic phase is a growth phase, the first detection sequence value is incremented using a preset increment parameter to update the first detection sequence value. The second detection sequence value is updated using the updated first detection sequence value and the maximum detection sequence value among the second detection sequence values.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: If there are new dependencies related to the local node in the shared memory corresponding to the local node, obtain the mapping relationship between each detection node and each node transaction in the local node; the new dependency is from the second waiting transaction in the local node to the second waiting transaction of the downstream node; If, based on the mapping relationship, it is determined that there is no detection node matching the second waiting transaction on the local node, then a blocking detection node corresponding to the second waiting transaction is created based on the waiting transaction information of the second waiting transaction; the blocking detection node is used to record waiting transactions that have a dependency relationship with the second waiting transaction. Based on the waiting transaction information, a second deadlock detection information is generated for the newly added dependency, and the second deadlock detection information is sent to the downstream node.

7. The method according to claim 6, characterized in that, The method further includes: The node survival time of the blockage detection node is obtained in real time; If the node's survival time exceeds a preset time threshold, the blocking detection node is deleted.

8. A database deadlock handling system, characterized in that, The system includes multiple data service nodes and auxiliary processes corresponding to each of the data service nodes; The data service node is used to manage at least one node transaction; The auxiliary process is used to implement the method as described in any one of claims 1 to 7.

9. The system according to claim 8, characterized in that, The system also includes a background process configured corresponding to the node transaction, and shared memory configured corresponding to each of the data service nodes; The background process is used to generate new dependencies related to the node transaction based on the transaction resource waiting information of the node transaction, and write the new dependencies into the shared memory that matches the local node, where the local node is a data service node used to manage the node transaction.

10. The system according to claim 9, characterized in that, The background process is also used to respond to resource release events for the node transaction and remove passive dependencies related to the node transaction from the shared memory.

11. The system according to claim 9, characterized in that, If there is an unlocked write location in the shared memory, the background process obtains the flag information of the historical dependencies stored in the write location. If the flag information indicates that the historical dependency is invalid, then the new dependency is written at the write position.

12. A database deadlock handling device, characterized in that, The device includes: The information receiving module is used to receive the first deadlock detection information sent by the upstream node for the target dependency relationship, and to determine the period stage of the local node in the deadlock detection period; the target dependency relationship is pointed from the first waiting transaction of the upstream node to the first waiting transaction of the local node; The blocking deduction module is used to perform blocking deduction on the first waited transaction based on the first deadlock detection information when the periodic phase is the propagation phase, and obtain the blocking deduction result. The deadlock handling module is used to delete the first awaited transaction and release the deadlock loop when the blocking deduction result indicates that the first awaited transaction is in a deadlock cycle and the first awaited transaction meets the unlocking condition.

13. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images