Database deadlock detection and analysis method, apparatus, device, and medium

Abstract

The application relates to the technical field of big data, and discloses a database deadlock detection and analysis method, which comprises the following steps: loading a configuration file and extracting monitoring interval parameters and log level parameters, connecting a target database according to the configuration file, periodically acquiring state information of transactions and resources through a database interface and storing the state information as state snapshots, initializing a data structure of a resource waiting graph, adding transaction nodes, resource nodes, request edges and occupation edges based on the state snapshots, performing a depth-first search on the resource waiting graph to detect whether a loop exists, judging whether the transactions and resources involved in the loop constitute a deadlock, recording relevant information, and generating a report on deadlock cause analysis and solutions based on transaction states, resource states, loop information, occupation relationships and waiting relationships. The application periodically collects state information of transactions and resources to construct state snapshots, and combines initialization and dynamic updating of the resource waiting graph, so that rapid positioning and accurate analysis of the deadlock problem are realized.

Description

Technical Field

[0001] This invention relates to the fields of big data technology and financial technology, and in particular to a database deadlock detection and analysis method, apparatus, device and storage medium. Background Technology

[0002] In modern financial database systems, efficient database operation is fundamental to ensuring the smooth functioning of core business operations such as financial transactions, account management, and risk control. However, in high-concurrency financial business scenarios, deadlock occurs frequently, becoming a significant source of database performance bottlenecks and stability risks. Deadlock typically occurs when two or more transactions are waiting for each other's resources, preventing them from continuing execution. This can lead to decreased system efficiency and even severely impact the overall stability of the financial system.

[0003] Currently, although there are some tools available for deadlock detection, these tools still have the following shortcomings in terms of functionality and efficiency:

[0004] Existing tools typically cannot monitor the status of database transactions and resources in real time, and cannot capture and analyze deadlock problems in a timely manner. This is especially true in scenarios with frequent financial transactions and high real-time requirements, where deadlock problems often cause delays.

[0005] Existing deadlock detection tools typically only provide basic deadlock detection functionality and struggle to generate detailed deadlock analysis reports. Users must manually analyze the causes of deadlocks, dependencies between transactions and resources, and solutions, which not only increases operational complexity but also reduces processing efficiency.

[0006] Existing tools typically only provide simple transaction termination suggestions after detecting deadlocks, lacking intelligent analysis of key indicators such as transaction priority and resource consumption time, and are unable to automatically select the optimal solution based on business scenarios.

[0007] While some tools can detect deadlock issues, they lack intuitive display of dependency chains and visualization of deadlock relationships. This makes it inefficient for users to understand the complex dependencies between transactions and resources, and they are prone to misjudgments.

[0008] Financial business scenarios are often accompanied by high-concurrency transaction requests and complex resource dependencies. Existing tools may be unable to effectively handle complex deadlock scenarios due to performance bottlenecks when dealing with large-scale transactions and resource relationships.

[0009] In summary, existing technologies have significant shortcomings in terms of real-time deadlock detection, automated analysis, intelligent solutions, and visualization capabilities. In particular, they cannot meet the needs of timely, accurate, and comprehensive handling of deadlock issues in high-concurrency business scenarios in the financial sector. Summary of the Invention

[0010] The main objective of this invention is to provide a database deadlock detection and analysis method, apparatus, device, and storage medium, aiming to solve the technical problems of low efficiency, lack of comprehensiveness and intelligence in the detection, analysis, and resolution of database deadlock problems in existing technologies, which are unable to meet the needs of complex business scenarios.

[0011] To achieve the above objectives, the present invention provides a database deadlock detection and analysis method, comprising:

[0012] Load the configuration file of the deadlock detection module, and extract the monitoring interval parameter and log level parameter from the configuration file;

[0013] Connect to the target database based on the target database information in the configuration file;

[0014] Based on the monitoring interval parameter, the status information of transactions and resources in the target database is periodically obtained through the database application interface, and the status information of transactions and resources is stored as a status snapshot;

[0015] Based on the state snapshot, initialize the data structure of the resource wait graph;

[0016] Based on the transaction identifier, resource identifier, and the request and occupancy relationship of the transaction to the resource contained in the state snapshot, add transaction nodes, resource nodes, request edges, and occupancy edges to the resource waiting graph;

[0017] A depth-first search traversal is performed on all nodes in the resource waiting graph to detect whether there are cycles in the resource waiting graph;

[0018] If a loop is detected in the resource waiting graph, it is determined that the transactions and resources involved in the loop constitute a deadlock, and the information of the transaction nodes and resource nodes in the loop, the occupancy relationship between the transaction nodes and resource nodes, and the waiting relationship between the transaction nodes are recorded.

[0019] Based on the status information of the transactions, the status information of the resources, the information of the transaction nodes and resource nodes in the loop, the occupancy relationship between the transaction nodes and resource nodes, and the waiting relationship between the transaction nodes, an analysis report containing deadlock cause analysis and solutions is generated.

[0020] Furthermore, to achieve the above objectives, the present invention provides a database deadlock detection and analysis device, comprising:

[0021] The configuration management module is used to load the configuration file of the deadlock detection module and extract the monitoring interval parameter and log level parameter from the configuration file.

[0022] The database connection module is used to connect to the target database according to the target database information in the configuration file;

[0023] The data acquisition module is used to periodically acquire the status information of transactions and resources in the target database through the database application interface according to the monitoring interval parameter, and store the status information of transactions and resources as a status snapshot;

[0024] The graph data initialization module is used to initialize the data structure of the resource wait graph based on the state snapshot.

[0025] The graph construction module is used to add transaction nodes, resource nodes, request edges, and occupy edges to the resource waiting graph based on the transaction identifier, resource identifier, and the request and occupancy relationship of the transaction to the resource contained in the state snapshot.

[0026] The loop detection module is used to perform a depth-first search traversal of all nodes in the resource waiting graph to detect whether there is a loop in the resource waiting graph;

[0027] The deadlock determination module is used to determine that the transactions and resources involved in the loop constitute a deadlock if a loop is detected in the resource waiting graph, and to record the information of the transaction nodes and resource nodes in the loop, the occupancy relationship between the transaction nodes and resource nodes, and the waiting relationship between the transaction nodes.

[0028] The analysis report generation module is used to generate an analysis report containing deadlock cause analysis and solutions based on the status information of the transaction, the status information of the resource, the information of the transaction nodes and resource nodes in the loop, the occupancy relationship between the transaction nodes and resource nodes, and the waiting relationship between the transaction nodes.

[0029] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a database deadlock detection and analysis program stored in the memory and executable on the processor, wherein when the database deadlock detection and analysis program is executed by the processor, it implements the steps of the database deadlock detection and analysis method as described above.

[0030] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a database deadlock detection and analysis program, wherein the database deadlock detection and analysis program, when executed by a processor, implements the steps of the database deadlock detection and analysis method as described above.

[0031] Beneficial Effects: This invention relates to the fields of big data technology and fintech, and discloses a database deadlock detection and analysis method. By loading a configuration file and extracting monitoring interval and log level parameters, the method connects to the target database according to the configuration file. It periodically acquires transaction and resource status information through the database interface and stores it as a status snapshot. The method initializes the data structure of a resource wait graph, adds transaction nodes, resource nodes, request edges, and occupancy edges based on the status snapshot, performs a depth-first search on the resource wait graph to detect the existence of loops, determines whether the transactions and resources involved in the loop constitute a deadlock, records relevant information, and generates a report analyzing the cause of the deadlock and providing solutions based on transaction status, resource status, loop information, occupancy relationships, and waiting relationships. This invention achieves rapid location and accurate analysis of deadlock problems by periodically collecting transaction and resource status information to construct status snapshots, combined with the initialization and dynamic updating of the resource wait graph. It efficiently detects loops in the resource wait graph through depth-first search, determines the cause of the deadlock, and generates an analysis report containing interaction paths, dependencies, and solutions, improving the intelligence and automation level of deadlock detection and handling. It is suitable for the stable operation and optimized management of databases in high-concurrency scenarios. Attached Figure Description

[0032] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings:

[0033] Figure 1 This is a schematic diagram of an application environment for a database deadlock detection and analysis method according to an embodiment of the present invention;

[0034] Figure 2 This is a flowchart illustrating an embodiment of the database deadlock detection and analysis method of the present invention;

[0035] Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the database deadlock detection and analysis device of the present invention;

[0036] Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention;

[0037] Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0038] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0039] The database deadlock detection and analysis method provided in this invention can be applied to, for example... Figure 1In this application environment, the user terminal communicates with the server via a network. The server can load a configuration file from the user terminal and extract monitoring interval and log level parameters. Based on the configuration file, it connects to the target database, periodically obtains transaction and resource status information through the database interface, stores it as a status snapshot, initializes the data structure of the resource wait graph, adds transaction nodes, resource nodes, request edges, and occupancy edges based on the status snapshot, performs a depth-first search on the resource wait graph to detect loops, determines whether the transactions and resources involved in the loop constitute a deadlock, records relevant information, and generates a report analyzing the cause of deadlock and providing solutions based on transaction status, resource status, loop information, occupancy relationships, and waiting relationships. This invention achieves rapid location and accurate analysis of deadlock problems by periodically collecting transaction and resource status information to construct status snapshots, combined with the initialization and dynamic updating of the resource wait graph; it efficiently detects loops in the resource wait graph through depth-first search, determines the cause of deadlock, and generates an analysis report containing interaction paths, dependencies, and solutions, improving the intelligence and automation level of deadlock detection and handling. It is suitable for the stable operation and optimization management of databases in high-concurrency scenarios. The user terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will now be described in detail through specific embodiments.

[0040] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the database deadlock detection and analysis method provided by the present invention. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0041] like Figure 2 As shown, the database deadlock detection and analysis method proposed in this invention includes the following steps:

[0042] S10, Load the configuration file of the deadlock detection module, and extract the monitoring interval parameter and log level parameter from the configuration file;

[0043] In this embodiment, loading the configuration file refers to reading the configuration content related to the deadlock detection module from storage media (such as a file system or database). These configuration files are typically stored in a structured format (such as JSON, YAML, or XML) and are used to define the operating parameters of the deadlock detection system, the connection information of the target database, and the monitoring strategy.

[0044] Load configuration file content using file reading APIs. For example, use Python's `open()` function or Java's `FileReader` class to read the file; check the configuration file format and integrity, ensuring that all required fields are present and free of syntax errors; parse the file content into a data structure supported by the programming language, such as parsing JSON into a dictionary or XML into a tree structure; if the configuration file is stored on a remote server or distributed storage system, the configuration content can be retrieved via REST API or message queues.

[0045] The monitoring interval parameter is used to set the time interval at which the deadlock detection module periodically obtains database status information, and it is a key configuration for periodic monitoring.

[0046] Read the corresponding fields from the parsed data structure, such as config["monitor_interval"]; verify the validity of the parameter values ​​to ensure that they are reasonable time units (such as seconds or milliseconds); save the monitoring interval parameter in a memory variable for subsequent operation; if the parameter is missing, provide a default value (such as setting it to 5 seconds).

[0047] The log level parameter defines the level of detail in the logs recorded by the deadlock detection module during operation, including levels such as debug information (DEBUG), operation logs (INFO), and exception information (ERROR).

[0048] Extract the log level field from the parsed configuration, such as config["log_level"]; verify the validity of the log level, allowing only predefined log levels (such as DEBUG, INFO, ERROR); configure the logger's operating mode, such as setting the log output level using Python's logging module or Java's Log4j framework; apply this parameter in the log initialization module to control the generation and storage behavior of logs.

[0049] By loading the configuration file and extracting key parameters, the deadlock detection module achieves dynamic configuration and flexible management. The monitoring interval parameter ensures that the module can run periodically, adapting to the real-time requirements of high-concurrency database environments; the log level parameter provides a flexible log management mechanism, helping users quickly locate problems during debugging, operation, and exception handling.

[0050] S20, Connect to the target database according to the target database information in the configuration file;

[0051] In this embodiment, connection information for the target database is extracted from the configuration file, including the database type (such as MySQL, PostgreSQL, Oracle, etc.), connection address (IP or domain name), port number, database name, username, password, and other information. This information is used to establish a communication channel with the target database.

[0052] Use the configuration file parsing module to obtain the corresponding field values, such as db_type, db_host, db_port, db_name, db_user, and db_password; verify that these fields are complete and valid to ensure that all the information required for the connection has been loaded correctly; if any fields are missing, return an error message and terminate the connection attempt.

[0053] The parsed database information is initialized into a connection configuration that can be used by the database driver. This includes mapping the database type to the driver (such as JDBC or ODBC), formatting the connection string, etc.

[0054] Select the appropriate driver or client library based on the database type, such as loading com.mysql.jdbc.Driver when using a JDBC driver; construct the connection string, for example: MySQL format: jdbc:mysql: / / <host> : <port> / <database>; PostgreSQL format: jdbc:postgresql: / / <host> : <port> / <database>Initialize the connection parameter object and fill in the corresponding fields with information such as username and password.

[0055] Establish a communication channel with the target database using the database driver to ensure a stable and usable connection. Initiate a connection request using APIs provided by the database driver or library, such as Java's `DriverManager.getConnection()` method or Python's `psycopg2.connect()` function. Upon successful connection, return a database connection object for subsequent queries. If the connection fails, catch the exception and return detailed error information, including reasons such as connection timeout, authentication failure, or target unreachable.

[0056] After establishing a database connection, verify its availability to ensure normal access to the target database. Test the connection by executing a simple query (such as SELECT 1); catch and handle exceptions during connection verification, retrying the connection or reporting errors.

[0057] By parsing the target database information in the configuration file, the database connection configuration is dynamically initialized and an efficient communication channel is established, enabling flexible support for multiple database types. Verifying the connection status ensures the reliability and stability of database communication, providing a foundational environment for subsequent transaction and resource monitoring.

[0058] S30, according to the monitoring interval parameter, periodically obtain the status information of transactions and resources in the target database through the database application interface, and store the status information of transactions and resources as a status snapshot;

[0059] In this embodiment, the time interval for periodically acquiring transaction and resource status information is set according to the monitoring interval parameter to ensure timely monitoring of the target database. This parameter directly affects the balance between the real-time performance of monitoring and system performance.

[0060] Use scheduling tools or task planning modules (such as ScheduledExecutorService in Java or the schedule library in Python) to set up scheduled tasks; initialize the time period of the scheduled tasks according to the monitoring interval parameters; after the trigger time arrives, call the database interface to obtain the status information of transactions and resources.

[0061] The database application programming interface (API) is used to query the current transaction status in the target database, including the transaction identifier and execution status (e.g., running, waiting, committed, rolled back). This information is used for subsequent resource wait graph construction and deadlock detection.

[0062] Use a database interface (such as JDBC, ODBC, or database management tools) to execute a transaction status query statement; example query statement:

[0063] MySQL:SELECT*FROM information_schema.innodb_trx;

[0064] PostgreSQL:SELECT*FROM pg_stat_activityWHERE state='active'.

[0065] The query results are parsed into data structures supported by the programming language (such as lists in Python and collections of objects in Java), and key information such as transaction identifiers and status is extracted.

[0066] Using the database application programming interface (API), query the current status of resources in the target database, including resource identifier, locking status (e.g., shared lock, exclusive lock), and a list of occupied and requested transactions. Execute the query statement to obtain the current resource's lock information;

[0067] MySQL example: SHOW ENGINE INNODB STATUS;

[0068] PostgreSQL example: SELECT * FROM pg_locks.

[0069] Parse the lock information to extract resource identifiers, currently occupying transactions, and waiting transaction queues; format the extracted results into structured data for use in subsequent steps.

[0070] The state information of transactions and resources is integrated into a state snapshot, which serves as the basis for constructing the resource wait graph and detecting deadlocks. The state snapshot describes the global state of transactions and resources at the current point in time.

[0071] Define the storage structure for state snapshots, such as an in-memory dictionary or a table in a database;

[0072] It can be stored in the following structure:

[0073] Transaction snapshot: Records the transaction status (e.g., running, waiting) using the transaction identifier as the primary key;

[0074] Resource snapshot: Using the resource identifier as the primary key, it records the occupying transactions and the waiting transaction queue;

[0075] Update the contents of the state snapshot in a periodic task to ensure that the data reflects the current state in real time; in high-performance scenarios, the snapshot can be stored in a caching system (such as Redis) to speed up reading.

[0076] By periodically acquiring the state information of transactions and resources in the target database and storing it as state snapshots, the system provides global and real-time foundational data for deadlock detection. Utilizing state snapshots, the system can quickly construct resource wait graphs and efficiently detect deadlocks, while avoiding the performance overhead caused by frequent database accesses. This makes it suitable for high-concurrency and complex transaction scenarios.

[0077] S40, Initialize the data structure of the resource wait graph based on the state snapshot;

[0078] In this embodiment, the resource wait graph is a directed graph used to describe the relationship between transactions and resources. Nodes in the graph represent transactions and resources, and edges represent requests or occupancy relationships of transactions for resources. Initializing the data structure of the resource wait graph is a fundamental operation for subsequent deadlock detection.

[0079] Choose a data structure: Select a suitable storage method based on the application scenario, such as adjacency list or adjacency matrix: Adjacency list: suitable for scenarios with a large number of transactions and resources but sparse relationships; Adjacency matrix: suitable for scenarios with denser transaction and resource relationships.

[0080] Set up the storage structure: Define the node storage structure and edge storage structure of the resource wait graph: Node storage structure: Use lists, dictionaries or database tables to store transaction nodes and resource nodes; Edge storage structure: Record the type (request edge or occupy edge) and direction of the edges.

[0081] Storage space allocation: Dynamically allocate storage space based on the number of transaction identifiers and resource identifiers in the state snapshot to ensure that the resource wait graph can accommodate all nodes and edge relationships.

[0082] The state snapshot contains the current state of transactions and resources. Initializing the resource wait graph requires extracting all transaction identifiers and resource identifiers from it, ensuring that each node in the graph uniquely maps to an identifier. The process involves traversing the transaction and resource information in the state snapshot, extracting transaction and resource identifiers, checking for duplicate identifiers, removing duplicates if found, generating corresponding nodes using the identifiers, and adding them to the graph.

[0083] Create mappings between transaction nodes and resource nodes in the resource wait graph, enabling quick location of the corresponding graph node using its identifier. Store the node mappings using a dictionary structure, with keys being either transaction identifiers or resource identifiers and values ​​being node indexes. Dynamically update the mappings to support subsequent node addition and deletion operations. Synchronize the mappings with the node storage structure to ensure consistency.

[0084] Based on the log level parameters, record detailed information about the resource wait graph initialization process, including data structure type, number of allocated nodes, and storage space size, for debugging and problem localization. Determine the log level:

[0085] DEBUG level: Records all initialization information, including the node creation process and storage allocation.

[0086] INFO level: Records key initialization steps and final results;

[0087] ERROR level: Only record exception information.

[0088] Use logging modules to output records, such as Python's logging module or Java's Log4j framework; store log information in files, databases, or monitoring systems to support subsequent analysis and backtracking.

[0089] By initializing the resource wait graph data structure based on state snapshots, the dependencies between transactions and resources are constructed, providing efficient and structured foundational data for subsequent deadlock detection. Dynamically allocating storage space and recording initialization process logs enhance the system's debugging capabilities and scalability, while ensuring the accuracy and real-time performance of the resource wait graph.

[0090] S50, based on the transaction identifier, resource identifier, and the request and occupancy relationship of the transaction to the resource contained in the state snapshot, add transaction nodes, resource nodes, request edges, and occupancy edges to the resource waiting graph;

[0091] In this embodiment, the identifiers of all current transactions and resources are obtained from the state snapshot to ensure that these entities are fully mapped in the resource wait graph. Transaction identifiers represent active transaction units, and resource identifiers represent locked or requested resource units.

[0092] Extract a list of transaction identifiers from the state snapshot to record all active transactions; extract a list of resource identifiers, including locked and requested resources; deduplicate identifiers to ensure that each transaction and resource is recorded only once; verify the integrity of the identifiers and filter out invalid or duplicate records.

[0093] Check the node set of the resource wait graph to determine if it already contains the transaction identifier and resource identifier extracted from the state snapshot. If not, add a new node and synchronize it to the resource wait graph.

[0094] For each transaction identifier, check if it already exists in the node set of the resource waiting graph; if not, create the transaction node and add it to the graph; similarly, perform the same operation for each resource identifier, creating the corresponding resource node; update the storage structure of the node set, mapping the newly added transaction node and resource node to the graph index.

[0095] Based on the resource request relationships of transactions in the state snapshot, a directed edge from the transaction node to the resource node is added to each request pair in the resource wait graph. The request edge indicates that the transaction is currently requesting the right to use the resource.

[0096] Traverse the request relationship records in the state snapshot; for each record, locate the graph node corresponding to the request transaction and the target resource; add directed edges from the transaction node to the resource node in the resource waiting graph; store the edge type and additional information (such as request time) in the edge storage structure.

[0097] Based on the resource occupancy relationships between transactions in the state snapshot, a directed edge from the resource node to the transaction node is added to each pair of occupancy relationships in the resource wait graph. The occupancy edge represents the usage rights of the resource currently held by the transaction.

[0098] Traverse the occupancy records in the state snapshot; for each record, locate the graph node corresponding to the occupied resource and the holding transaction; add directed edges from the resource node to the transaction node in the resource waiting graph; store the edge type and additional information (such as occupancy duration) in the edge storage structure.

[0099] After completing the node and edge addition operations, update the node set and edge storage structure of the resource waiting graph to ensure that the graph structure is complete and consistent with the state snapshot.

[0100] Record newly added nodes and edges into the node set and edge storage structure; if the number of nodes or edges exceeds the current storage space, dynamically expand the storage structure; verify the correctness of the graph structure to ensure that there are no duplicate nodes or edges.

[0101] By dynamically adding transaction nodes, resource nodes, request edges, and occupancy edges to the resource wait graph, a comprehensive dependency graph of transactions and resources is constructed, ensuring that the basic data for deadlock detection is accurate and real-time. Through an efficient node and edge management mechanism, diverse database scenarios are supported, while the graph's storage structure and update performance are optimized.

[0102] S60, perform a depth-first search traversal of all nodes in the resource waiting graph to detect whether there is a cycle in the resource waiting graph;

[0103] In this embodiment, before the depth-first search traversal begins, resources need to be initialized to wait for the state of all nodes in the graph, each node is marked as unvisited, and a recursive stack is set up to record the nodes on the current path to facilitate the detection of loops.

[0104] Create a status flag for each node in the resource wait graph, with a value of "unvisited", "visiting", or "visited"; use a data structure (such as a stack or list) to store the nodes on the recursive path; ensure that the recursive stack is empty when the search begins.

[0105] Select an unvisited node from the resource waiting graph as the starting node for a depth-first search, ensuring that all nodes are checked, even if the graph is disconnected. Traverse the set of nodes in the resource waiting graph, searching for nodes in the unvisited state; use the found node as the starting point of the current search path; if all nodes have been visited, end the search.

[0106] The system recursively traverses all adjacent nodes connected to the current node, marks the access status of each node, and records the visited nodes along the search path.

[0107] Mark the current node's state as "being visited"; add the current node to the recursion stack; traverse all adjacent nodes of the current node. If an adjacent node is "not visited", then recursively call a depth-first search; if an adjacent node is "being visited" and exists in the recursion stack, then a loop is detected.

[0108] After the depth-first search is completed, backtrack the search path, update the state of the current node to "visited", and remove it from the recursion stack.

[0109] Check if all adjacent nodes of the current node have been visited; if all have been visited, mark the current node's state as "visited"; remove the current node from the recursion stack and continue backtracking to the previous level of nodes.

[0110] If the recursive stack detects that the currently accessed node already exists during the search process, it indicates that there is a loop in the path, i.e., a deadlock has occurred.

[0111] When traversing adjacent nodes, if the current adjacent node is in the state of "being visited" and the node exists in the recursion stack, then record the loop information; immediately terminate the recursive search and return the detection result; if all nodes have been visited and no loop has been detected, then it is determined that there is no loop in the resource waiting graph.

[0112] Efficient loop detection is achieved by performing a depth-first search traversal of all nodes in the resource wait graph. By marking node states and using a recursive stack, circular dependencies between transactions and resources can be accurately identified, providing a foundation for subsequent deadlock analysis and resolution. The adoption of dynamic path recording and backtracking mechanisms ensures the algorithm's efficiency and correctness, making it suitable for high-concurrency and complex transaction scenarios.

[0113] S70, if a loop is detected in the resource waiting graph, it is determined that the transactions and resources involved in the loop constitute a deadlock, and the information of the transaction nodes and resource nodes in the loop, the occupancy relationship between the transaction nodes and resource nodes, and the waiting relationship between the transaction nodes are recorded.

[0114] In this embodiment, by detecting the loop in the resource wait graph, it is confirmed whether there is a mutually dependent circular relationship between transactions and resources. If a loop exists, it is determined that the transactions and resources in the loop have formed a deadlock.

[0115] The recursive stack of depth-first search is used to record the nodes on the current path; when a node is detected to appear repeatedly in the path, it is marked as a cycle; all nodes in the cycle are used as the scope of deadlock-related transactions and resources.

[0116] Record the basic information of all transaction nodes and resource nodes involved in the loop to provide a basis for subsequent deadlock analysis and resolution.

[0117] Obtain the identifiers of transaction nodes and resource nodes (such as node ID, name, or unique identifier); extract additional information about the nodes, such as the execution status of the transaction and the current locking status of the resource; organize the information and store it as a loop node record table for later use.

[0118] Record the relationship between transaction nodes and resource nodes in the loop, indicating which resources are held by which transactions.

[0119] Traverse all transaction nodes and resource nodes in the loop; check if each transaction node has an occupation edge with a resource node; if an occupation edge exists, record additional information such as the occupation time and type (e.g., exclusive lock or shared lock) of the transaction node on the resource node.

[0120] Record the waiting relationships between transaction nodes in the loop, indicating which transactions are waiting for other transactions to release resources. Traverse all transaction nodes in the loop; check if there are waiting edges between transaction nodes (such as relationships in a waiting queue); record additional information about the waiting relationships, including waiting time, blocked transactions and their priorities, etc.

[0121] The information on transaction nodes, resource nodes, occupancy relationships, and waiting relationships in the recorded loop is archived and stored to provide data support for the subsequent generation of analysis reports and solutions.

[0122] Organizational information is in a uniform structured format, such as JSON, tables, or database records; detailed or summary information is recorded based on log level parameters; information is stored in files, databases, or monitoring systems.

[0123] By detecting loops in the resource wait graph and recording detailed information about transaction nodes and resource nodes within the loops, their occupancy relationships, and waiting relationships, the root cause of deadlocks was accurately identified. This recorded information provided high-quality input data for subsequent deadlock analysis and resolution, improving system reliability and troubleshooting efficiency.

[0124] S80, based on the status information of the transaction, the status information of the resource, the information of the transaction node and the resource node in the loop, the occupancy relationship between the transaction node and the resource node, and the waiting relationship between the transaction nodes, an analysis report containing deadlock cause analysis and solutions is generated.

[0125] In this embodiment, transaction status information, resource status information, information about transactions and resource nodes in the loop, the occupancy relationship between transactions and resources, and the waiting relationship between transaction nodes are integrated into a unified dependency model. This dependency model provides data support for deadlock analysis and solutions.

[0126] Extract transaction status information from the records, including transaction ID, current status (running, waiting, etc.), and priority; extract resource status information, including resource ID, currently occupied transaction, and list of waiting transactions; combine the information of transaction nodes and resource nodes involved in the loop to construct a dependency link graph between transactions and resources; use a graph structure to store node relationships, mapping occupancy and waiting relationships to directed edges in the graph; verify the integrity of the dependency model to ensure that all nodes and relationships are correctly included in the model.

[0127] Based on the dependency chain graph analysis, the interaction path between transactions and resources can be identified to determine the specific causes of deadlocks, including circular dependencies between transactions or resources being occupied for a long time without being released.

[0128] Traverse all loops in the dependency chain graph and extract the transactions and resources involved in the loops; check whether there are circular dependencies in the resource request paths of each transaction; count the resource occupancy time, and mark it as a possible cause if it exceeds a preset threshold and is not released; combine loop analysis and occupancy time statistics to generate a detailed list of deadlock causes.

[0129] Based on the cause of the deadlock, and combining priority and occupancy time strategies, determine a solution suitable for the current deadlock scenario. If low-priority transactions exist in the loop, it is recommended to terminate low-priority transactions to release resources; if the resource occupancy time exceeds the threshold, it is recommended to release resources with longer occupancy times; if the transaction priorities are similar, it is recommended to adjust the execution order of transactions to break the circular dependency; categorize the determined solutions into different strategies and record the applicable scenarios for each strategy.

[0130] The integrated data sources, interaction path analysis results, and solutions are organized into a structured analysis report, making it easy for users to understand and implement.

[0131] Format the information of transaction and resource nodes in the loop to generate detailed descriptions of transactions and resources; display the dependency chain diagram using graphical tools or structured formats; list the results of deadlock cause analysis in the form of entries, including circular dependencies and time-consuming issues; clearly present the solutions, sort them by priority and attach applicable suggestions; output the analysis report as a log file or send it to the administrator through the notification module.

[0132] By integrating transaction status information, resource status information, nodes in loops, and dependencies, a dependency graph of transactions and resources can be quickly constructed, enabling precise analysis of deadlock causes. It can efficiently generate analysis reports containing deadlock causes and solutions, providing users with clear guidance on deadlock handling, improving database management efficiency, and preventing prolonged system downtime.

[0133] This invention relates to the fields of big data technology and fintech, and discloses a database deadlock detection and analysis method. It loads a configuration file and extracts monitoring interval and log level parameters. Based on the configuration file, it connects to the target database and periodically acquires transaction and resource status information through the database interface, storing it as a status snapshot. It initializes the data structure of a resource wait graph, adds transaction nodes, resource nodes, request edges, and occupancy edges based on the status snapshot, performs a depth-first search on the resource wait graph to detect the existence of cycles, determines whether the transactions and resources involved in the cycle constitute a deadlock, records relevant information, and generates a report analyzing the cause of the deadlock and providing solutions based on transaction status, resource status, cycle information, occupancy relationships, and waiting relationships. This invention achieves rapid location and accurate analysis of deadlock problems by periodically collecting transaction and resource status information to construct status snapshots, combined with the initialization and dynamic updating of the resource wait graph. It efficiently detects cycles in the resource wait graph through depth-first search, determines the cause of the deadlock, and generates an analysis report containing interaction paths, dependencies, and solutions, improving the intelligence and automation level of deadlock detection and handling. It is suitable for the stable operation and optimized management of databases in high-concurrency scenarios.

[0134] In one embodiment, S40 includes:

[0135] S401, Select the data structure for the resource waiting graph and use an adjacency list or adjacency matrix as the representation method for the resource waiting graph;

[0136] S402, based on the number of transaction identifiers and resource identifiers in the state snapshot, allocate storage space for the information of transaction nodes and resource nodes in the resource waiting graph, and initialize the storage structure of transaction nodes and resource nodes;

[0137] S403, Create a mapping table between the transaction node and the resource node. The mapping table is used to record the mapping relationship between the transaction identifier and the resource identifier to the corresponding node index in the resource waiting graph.

[0138] S404, based on the log level parameters, record detailed information about the resource waiting graph initialization process, including data structure type, number of nodes, and storage space size.

[0139] In this embodiment, the resource wait graph is a key data structure that describes the relationship between transactions and resources, and is used to store the dependencies, requests, occupancy and other relationships between transactions and resources.

[0140] Adjacency lists and adjacency matrices are common representations of resource wait graphs, each with its own applicable scenarios:

[0141] Adjacency lists are suitable for graphs with sparse nodes and edges, offering high storage efficiency and flexible querying; adjacency matrices are suitable for graphs with dense nodes and edges, allowing for quick access to the relationships between specific nodes.

[0142] Determine the number of transaction identifiers and resource identifiers to estimate the sparsity of the graph; select either an adjacency list or an adjacency matrix as the graph representation based on the estimation results; initialize the data structure:

[0143] Adjacency list: A list is allocated for each node to store adjacent nodes;

[0144] Adjacency matrix: Creates a two-dimensional array to represent the edge relationships between nodes.

[0145] Allocate sufficient storage space to support the information storage of all transaction nodes and resource nodes; initialize the storage structure to record node attributes, such as identifiers and current states.

[0146] Extract the total number of transaction identifiers and resource identifiers from the state snapshot; calculate storage requirements:

[0147] Adjacency list: Allocates a dynamic list or linked list for each node;

[0148] Adjacency matrix: Initializes a two-dimensional array based on the total number of nodes, with a default value of 0 or empty;

[0149] Initialize the node attribute storage structure, including basic information (identifier, status, occupied or waiting time, etc.) for transaction nodes and resource nodes.

[0150] The purpose of the mapping table is to quickly find the node index corresponding to the transaction identifier and resource identifier in the resource waiting graph; through the mapping table, node information can be updated and queried efficiently.

[0151] Create a mapping table structure, commonly implemented as a hash table or dictionary; traverse the transaction identifiers and resource identifiers in the state snapshot, generating a unique index for each identifier; store the transaction identifiers and resource identifiers along with their corresponding node indexes in the mapping table for easy and fast lookup.

[0152] Information generated during initialization, including graph type, number of nodes, and storage space size, supports debugging, monitoring, and problem diagnosis. Log level parameters control the level of detail recorded; common levels include DEBUG (verbose) and INFO (brief).

[0153] Determine the current log level;

[0154] DEBUG: Records detailed information about all operations during the initialization process, including node allocation, data structure selection, etc.

[0155] INFO: Only records information about key steps, such as graph type, number of nodes, and storage space size;

[0156] The initialization information is formatted and written to a log file or logging system.

[0157] This embodiment initializes the data structure of the resource wait graph based on a state snapshot, quickly building a graph model of transaction and resource relationships. Based on the flexible graph representation method, efficient storage structure for nodes and edges, and fast indexing capability of the mapping table, it significantly improves the construction efficiency of the resource wait graph and data query performance, laying a solid foundation for subsequent loop detection and deadlock analysis.

[0158] In one embodiment, the above S50 includes:

[0159] S501, traverse all transaction identifiers and resource identifiers recorded in the state snapshot, and read the request relationship of the transaction to the resource and the occupation relationship of the resource to the transaction one by one;

[0160] S502, check the node set of the resource wait graph to confirm whether the node set contains all transaction identifiers and resource identifiers;

[0161] S503, if there are unincluded transaction identifiers or resource identifiers, then create a transaction node corresponding to the transaction identifier or a resource node corresponding to the resource identifier, and add the transaction node or resource node to the node set of the resource waiting graph;

[0162] S504, based on the resource request relationship of the transaction, add a request edge from the transaction node to the resource node in the resource waiting graph, and record the type and relationship of the request edge in the edge storage structure of the resource waiting graph;

[0163] S505, based on the resource-transaction occupancy relationship, add an occupancy edge from the resource node to the transaction node in the resource waiting graph, and record the type and relationship of the occupancy edge in the edge storage structure of the resource waiting graph.

[0164] In this embodiment, transaction identifiers and resource identifiers are obtained from the state snapshot, and the request and occupancy relationships between transactions and resources are read sequentially to ensure that all data is processed one by one.

[0165] Request relationship: Indicates a transaction requesting access to a resource.

[0166] Occupation relationship: Indicates that a resource is occupied by a transaction.

[0167] Use iterators or loops to read state snapshots one by one; extract transaction identifiers and resource identifiers; parse request and occupancy relationships for each record to ensure data integrity.

[0168] Check if the corresponding transaction and resource node already exist in the resource wait graph to avoid duplicate creation; the node set is the collection of existing nodes in the resource wait graph, including transaction nodes and resource nodes.

[0169] Traverse the node set of the resource wait graph; check if the corresponding node already exists by comparing the current transaction identifier and resource identifier; mark the transaction identifier and resource identifier that are not included to provide a basis for subsequent operations.

[0170] For transaction identifiers and resource identifiers not included in the node set, create new transaction nodes and resource nodes respectively; add the created nodes to the resource wait graph and update the node set.

[0171] Create a node object for each transaction identifier and resource identifier; the node object contains basic attributes such as identifier, node type (transaction or resource), etc.; call the add node function of the resource wait graph to insert the node into the node set.

[0172] A request edge is a directed edge in a resource wait graph, representing a transaction's request for a resource; the type and relationship of the request edge indicate the specific nature of the request (such as a read / write request).

[0173] Iterate through all the request relationships of transactions; find the corresponding transaction node and resource node in the resource waiting graph; create request edges from the transaction node to the resource node, and record the attributes (type, relationship, etc.) of the edges in the edge storage structure; add the request edges to the edge set of the resource waiting graph.

[0174] Occupied edges are directed edges in a resource wait graph, indicating that resources are occupied by transactions; the type and relationship of occupied edges indicate the specific occupancy details (such as lock type, occupancy time, etc.).

[0175] Iterate through the occupancy relationships of all resources; find the corresponding resource nodes and transaction nodes in the resource waiting graph; create occupancy edges from resource nodes to transaction nodes, and record the attributes (type, relationship, etc.) of the edges in the edge storage structure; add the occupancy edges to the edge set of the resource waiting graph.

[0176] This embodiment analyzes the request and occupancy relationships between transactions and resources in the state snapshot, accurately adding transaction nodes, resource nodes, request edges, and occupancy edges to the resource waiting graph, thus achieving dynamic updates of resource dependencies. The efficient management of node sets and edge storage structures significantly improves the construction speed and update performance of the resource waiting graph, providing a reliable foundation for subsequent deadlock detection.

[0177] In one embodiment, S60 includes:

[0178] S601, initialize the state of all nodes in the resource waiting graph to be unvisited, and set up a recursive stack to record the node information of the current path;

[0179] S602, Select an unvisited node from the resource waiting graph as the starting node, and perform a depth-first search traversal in a recursive manner;

[0180] S603, during the depth-first search process, the current node is marked as being visited, and the connected nodes connected to the current node are visited in sequence. If a connected node is detected to already exist in the recursion stack, it is determined that a loop exists.

[0181] S604, when all connected nodes of the current node have been visited, mark the current node as visited and remove the current node from the recursion stack.

[0182] In this embodiment, all nodes are initialized to an "unvisited" state to ensure that traversal starts from the initial state without state interference; a recursive stack is set up to record the node information in the current path of depth-first search (DFS) to facilitate the determination of whether a cycle has been formed.

[0183] Traverse all nodes in the resource waiting graph and set their status to "unvisited"; initialize the recursive stack as an empty list or empty stack data structure; dynamically store the nodes in the current access path in the recursive stack for loop detection.

[0184] Choosing an unvisited node as the starting point avoids repeated traversal; the recursive approach facilitates handling complex dependencies between nodes and is compatible with loop detection.

[0185] Traverse the set of nodes and find the node whose state is "unvisited"; call the recursive function to perform DFS traversal on the starting node; push the current node onto the recursive stack; set the current node's state to "being visited"; traverse the current node's adjacent nodes and recursively call DFS.

[0186] Mark the node status as "being visited" to ensure that the current node is unique in the recursive path; if the connected node is already in the recursive stack, a loop is formed, and the loop determination result is returned directly.

[0187] Traverse the adjacent nodes of the current node and check the state of each adjacent node: if the state is "unvisited", recursively call DFS; if the state is "being visited" and the node already exists in the recursion stack, it is determined that a cycle exists; record the node sequence that forms the cycle.

[0188] After all connected nodes of the current node have been visited, update the node's state to "visited"; remove the current node from the recursion stack to maintain the correctness of the recursion path.

[0189] In the recursive function, check if all adjacent nodes of the current node have completed DFS; if all have, update the current node's state to "visited"; pop the current node from the recursive stack and end the current recursive call.

[0190] This embodiment achieves rapid detection of cycles in the resource waiting graph and accurately identifies circular dependencies between transactions and resources by performing a depth-first search traversal of all nodes in the graph. The introduction of a recursive stack improves the accuracy of cycle detection, and node state management ensures the efficiency of graph traversal, providing strong technical support for deadlock detection.

[0191] In one embodiment, in step S70 above, if a loop is detected in the resource wait graph, after determining that the transactions and resources involved in the loop constitute a deadlock, the method further includes:

[0192] S701, at least one transaction is selected to be terminated based on transaction priority or scope of impact to resolve the deadlock;

[0193] S702, perform a rollback operation on the terminated transaction to release the occupied resources and restore the target database to its normal state;

[0194] S703, record information on transaction termination and rollback operations during the deadlock resolution process according to the log level parameters.

[0195] In this embodiment, after a loop is detected in the resource wait graph, all transactions in the loop participate in a deadlock. To resolve the deadlock, at least one transaction must be terminated.

[0196] Each transaction is assigned a priority based on business rules, importance, or other attributes. For example, read transactions may have a lower priority than write transactions, and ordinary query transactions may have a lower priority than financial transfer transactions.

[0197] The scope of impact refers to the potential consequences of terminating a transaction on the system, such as the possibility of data loss, the number of affected users, or the scope of system functionality. Transactions with a smaller scope of impact should be terminated first.

[0198] The process of selecting transactions involves analyzing and comparing the priority or scope of influence of transactions in the loop to ensure that the impact on system performance and business functions is minimized.

[0199] Obtain the identifiers of all transactions in the loop: Extract the identifiers of all transaction nodes from the loop detection results of the resource wait graph.

[0200] Retrieve transaction priority and scope of impact: Read priority information for each transaction from system configuration or transaction logs; if priority information is missing, infer priority based on transaction type (e.g., query, write operation); determine the scope of impact of the transaction by analyzing the resources affected by the transaction and the scope of related user operations.

[0201] Compare transaction priorities and scope of impact: sort by priority from low to high; if priorities are the same, sort by scope of impact from small to large.

[0202] Select the optimal transaction to terminate: Select the transaction with the lowest priority or the smallest impact as the termination target; record detailed information about the selection process to ensure that the selection logic is traceable.

[0203] After terminating a transaction, a rollback operation must be performed to undo the partially executed operations and release resources. This ensures that the target database is in a consistent state after the rollback is complete. The resources released during the rollback can then be used by other transactions.

[0204] Call the database rollback interface: Send a rollback command to the database system using the transaction identifier; ensure that the rollback operation is executed synchronously with the transaction log.

[0205] Release resources held by terminated transactions: During the rollback process, mark the resource status as "unheld"; add the released resources back into the available resource pool.

[0206] Check the recovery status of the target database: verify whether there are any unreleased resources or data anomalies after the rollback; if there are problems, record the anomalies and trigger further processing procedures.

[0207] Record the deadlock resolution process to facilitate problem review and system performance analysis; different log levels record the following content: DEBUG: records the detailed logic of transaction priority and impact scope analysis; INFO: records the transaction termination indicator and rollback completion status.

[0208] Select log recording content: Determine the granularity of information to be recorded based on the current log level parameters;

[0209] The generated log content includes information such as transaction identifier, selection criteria, and rollback status; the DEBUG level may include detailed logic regarding analysis priority and scope of impact.

[0210] Save logs: Write logs to files, databases, or other log management systems.

[0211] This embodiment selects transactions to be terminated based on transaction priority or scope of impact, and combines this with rollback operations to release resources and restore the database state. This effectively resolves deadlock issues while minimizing the impact on system performance and business functionality. The logging function provides detailed evidence for subsequent problem analysis, enhancing system maintainability.

[0212] In one embodiment, the above S80 includes:

[0213] S801, integrate the transaction status information, resource status information, information of transaction nodes and resource nodes in the loop, as well as the occupancy and waiting relationships between transaction nodes and resource nodes, to construct a dependency link graph between transactions and resources;

[0214] S802, Based on the dependency link graph, analyze the interaction path between transactions and resources, and determine the specific cause of deadlock. The specific cause includes circular dependencies between transactions or the time that resources are occupied by transactions exceeds a preset time threshold.

[0215] S803, determine a solution based on the specific reason, the solution including terminating low-priority transactions, releasing resources that have been occupied for more than a preset time threshold, or adjusting the execution priority of transactions;

[0216] S804, Generate an analysis report, which includes detailed information on transaction nodes and resource nodes, dependency chain diagrams, deadlock cause analysis, and solutions.

[0217] In this embodiment, all state information of transactions and resources is integrated, and the transaction nodes, resource nodes in the loop are associated with their relationship information to construct a clear dependency chain graph. The nodes in the dependency chain graph represent transactions or resources, and the edges represent the request or occupancy relationships between transactions and resources, which can intuitively display the dependency paths related to deadlock.

[0218] Extracting status and relationship information: Obtain transaction identifiers and statuses from transaction status information; obtain resource identifiers and statuses from resource status information; and obtain the dependencies between transaction nodes and resource nodes from loop detection results.

[0219] Construct a link graph data structure: Use graph theory to represent the dependency link graph, and use an adjacency list or adjacency matrix to represent the relationship between transactions and resources; add transaction nodes and resource nodes to the graph structure, and use occupancy relationships and request relationships as directed edges of the graph.

[0220] Integrate data into the dependency graph: Add nodes and edges sequentially to form a complete dependency graph; attach state information (such as transaction priority, resource status, etc.) to each node and edge in the graph.

[0221] By analyzing the interaction paths in the dependency graph, key dependencies between transactions and resources and the causes of deadlocks can be identified. Specific causes include:

[0222] Circular dependency between transactions: There are loops between transactions, causing them to wait for each other.

[0223] Resource occupied for a long time: A resource is occupied by transactions for a period of time exceeding a preset time threshold, resulting in the resource becoming unavailable.

[0224] Traverse the dependency graph using either depth-first search or breadth-first search; record the interaction relationships between transactions and resources on each path. Search for cycles in the paths to determine if circular dependencies exist between transactions; if so, mark the nodes and edges in the cycle as deadlock causes. Check if the resource occupancy time exceeds a preset threshold; if it does, mark the relevant transactions and resources as deadlock causes.

[0225] Determine the optimal solution based on the specific cause of the deadlock:

[0226] Terminate low-priority transactions: Release resources held by low-priority transactions;

[0227] Release long-occupied resources: Force the release of resources that have been occupied for an extended period;

[0228] Adjust transaction execution priority: Dynamically increase the priority of critical transactions to break circular waits.

[0229] Identify circularly dependent nodes or timed-out nodes from the dependency chain graph; formulate handling strategies based on transaction priorities or resource importance. Through priority ranking or impact scope analysis, select to terminate low-priority transactions or release timed-out resources; if no suitable transaction to terminate is found, dynamically adjust transaction execution priorities. Record the selected solution and execution steps in the log to ensure subsequent traceability.

[0230] The generated analysis report summarizes all key information about the deadlock issue, allowing users to intuitively understand the problem and implement solutions. The report includes:

[0231] Detailed information: Status, priority, and duration of transaction and resource nodes;

[0232] Dependency chain diagram: The diagram illustrates the dependencies between transactions and resources;

[0233] Deadlock cause analysis: Detailed description of circular dependencies or timeouts;

[0234] Solution: Suggested steps and reasons.

[0235] Extract information from dependency graphs, deadlock root cause analysis, and solutions; organize data in a structured format (tables, diagrams). Generate report documents using text processing tools or templates; report document formats support text, charts, and image embedding. Save reports to a specified storage location; support displaying reports via a user interface or sending them to administrators.

[0236] This embodiment integrates transaction and resource status information as well as dependencies to generate a dependency chain diagram and analyze the causes of deadlocks, which helps to quickly locate the source of the problem. By combining the specific reasons for circular dependencies and resource occupancy time, the optimal solution is formulated, and the generated analysis report provides an intuitive display of key information and clear handling suggestions, improving the efficiency of deadlock detection and resolution.

[0237] In one embodiment, after S80 above, the following is further included:

[0238] S901, the analysis report is sent to the management module through the message notification module;

[0239] S902, The management module displays the execution options of the solution in the analysis report through a user interface. The execution options include terminating the transaction or releasing resources.

[0240] S903, receive the selection information of the execution option in the user interface, and execute the corresponding solution operation according to the selection information.

[0241] In this embodiment, after the analysis report is generated, it is sent to the management module through the message notification module for subsequent display and operation; the message notification module can be implemented based on message queues, event notifications or network transmission protocols.

[0242] Organize the generated analysis report into structured data, such as JSON or XML format; ensure the data includes a report title, key content, and a solution summary. Send messages to the management module using a message queue (such as RabbitMQ or Kafka) or HTTP interface; the message content includes the analysis report's metadata and storage location (such as file path or database ID). The message notification module returns the sending status; if sending fails, record the reason for the failure and retry.

[0243] The user interface of the management module displays the report content and solution execution options; the execution options provide administrators with operation guidance, mainly including specific steps to terminate transactions or release resources.

[0244] The management module retrieves and analyzes report data based on the report storage location specified in the notification message; it then parses the data and loads it into the user interface. Based on the solution content in the analysis report, it dynamically generates execution option buttons or drop-down menus; options include operations such as terminating the transaction and releasing resources, along with brief descriptions of additional operations. The interface layout is clear, including report details and solution option areas; it provides basic interactive functions such as option selection and confirmation.

[0245] Users select the execution options for the solution through the interface; the system receives the selection information and triggers the corresponding operation logic.

[0246] The user interface binds an event listener to each execution option; it receives user selection information and records the selected option and operation parameters. It checks whether the selected option matches the solution scope of the current analysis report; for operations that do not meet the criteria, it returns an error message. If the user chooses to terminate the transaction, it calls the transaction management interface to terminate the selected transaction and release resources; if the user chooses to release resources, it calls the resource management module to update the resource status to "available". It records the operation execution time, the selected option, and its result; the result is stored in the log system for subsequent auditing.

[0247] This embodiment utilizes a message notification module and user interface to quickly transmit and display analysis reports to the management module, allowing users to intuitively view report content and implement solutions. This method improves the efficiency and accuracy of deadlock handling while providing comprehensive logging support for subsequent auditing.

[0248] In one embodiment, a database deadlock detection and analysis device is provided, which corresponds one-to-one with the database deadlock detection and analysis method described in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the database deadlock detection and analysis device of the present invention. The modules include a configuration management module 10, a database connection module 20, a data acquisition module 30, a graph data initialization module 40, a graph construction module 50, a loop detection module 60, a deadlock determination module 70, and an analysis report generation module 80. Detailed descriptions of each functional module are as follows:

[0249] The configuration management module 10 is used to load the configuration file of the deadlock detection module and extract the monitoring interval parameter and log level parameter from the configuration file.

[0250] Database connection module 20 is used to connect to the target database according to the target database information in the configuration file;

[0251] The data acquisition module 30 is used to periodically acquire the status information of transactions and the status information of resources in the target database through the database application interface according to the monitoring interval parameter, and store the status information of transactions and the status information of resources as a status snapshot;

[0252] Graph data initialization module 40 is used to initialize the data structure of the resource wait graph based on the state snapshot;

[0253] Graph construction module 50 is used to add transaction nodes, resource nodes, request edges, and occupy edges to the resource waiting graph based on the transaction identifier, resource identifier, and the request and occupancy relationship of the transaction to the resource contained in the state snapshot.

[0254] The loop detection module 60 is used to perform a depth-first search traversal of all nodes in the resource waiting graph to detect whether there is a loop in the resource waiting graph;

[0255] The deadlock determination module 70 is used to determine that the transactions and resources involved in the loop constitute a deadlock if a loop is detected in the resource waiting graph, and to record the information of the transaction nodes and resource nodes in the loop, the occupancy relationship between the transaction nodes and resource nodes, and the waiting relationship between the transaction nodes.

[0256] The analysis report generation module 80 is used to generate an analysis report containing deadlock cause analysis and solutions based on the status information of the transaction, the status information of the resource, the information of the transaction nodes and resource nodes in the loop, the occupancy relationship between the transaction nodes and resource nodes, and the waiting relationship between the transaction nodes.

[0257] In one embodiment, the graph data initialization module 40 is specifically used for:

[0258] Choose a data structure for the resource waiting graph and use an adjacency list or adjacency matrix as the representation method for the resource waiting graph;

[0259] Based on the number of transaction identifiers and resource identifiers in the state snapshot, allocate storage space for the information of transaction nodes and resource nodes in the resource wait graph, and initialize the storage structure of transaction nodes and resource nodes.

[0260] Create a mapping table between the transaction nodes and resource nodes. The mapping table is used to record the mapping relationship between the transaction identifier and the resource identifier to the corresponding node index in the resource wait graph.

[0261] Based on the log level parameters, record detailed information about the resource waiting graph initialization process, including data structure type, number of nodes, and storage space size.

[0262] In one embodiment, the graph construction module 50 is specifically used for:

[0263] Iterate through all transaction identifiers and resource identifiers recorded in the state snapshot, and read the transaction's request relationship to the resource and the resource's occupation relationship to the transaction one by one;

[0264] Check the node set of the resource wait graph to confirm whether the node set contains all transaction identifiers and resource identifiers;

[0265] If there are any unincluded transaction identifiers or resource identifiers, then create a transaction node corresponding to the transaction identifier or a resource node corresponding to the resource identifier, and add the transaction node or resource node to the node set of the resource waiting graph.

[0266] Based on the resource request relationship of the transaction, add request edges from the transaction node to the resource node in the resource waiting graph, and record the type and relationship of the request edges in the edge storage structure of the resource waiting graph;

[0267] Based on the resource-transaction occupancy relationship, an occupancy edge pointing from the resource node to the transaction node is added to the resource waiting graph, and the type and relationship of the occupancy edge are recorded in the edge storage structure of the resource waiting graph.

[0268] In one embodiment, the loop detection module 60 is specifically used for:

[0269] Initialize the state of all nodes in the resource waiting graph to unvisited, and set up a recursive stack to record node information of the current path;

[0270] Select an unvisited node from the resource waiting graph as the starting node, and perform a depth-first search traversal recursively.

[0271] During the depth-first search process, the current node is marked as being visited, and the connected nodes connected to the current node are visited in turn. If a connected node is detected to already exist in the recursion stack, it is determined that a loop exists.

[0272] When all connected nodes of the current node have been visited, the current node is marked as visited and removed from the recursion stack.

[0273] In one embodiment, the deadlock determination module 70 is specifically used for:

[0274] At least one transaction is terminated based on transaction priority or scope of impact to resolve the deadlock;

[0275] Perform a rollback operation on the terminated transaction to release the occupied resources and restore the target database to its normal state;

[0276] The log level parameters are used to record information about transaction termination and rollback operations during the deadlock resolution process.

[0277] In one embodiment, the analysis report generation module 80 is specifically used for:

[0278] The transaction status information, resource status information, information on transaction nodes and resource nodes in the loop, and the occupancy and waiting relationships between transaction nodes and resource nodes are integrated to construct a dependency link graph between transactions and resources.

[0279] Based on the dependency chain graph, the interaction path between transactions and resources is analyzed to determine the specific reasons for deadlock formation. The specific reasons include circular dependencies between transactions or resources being occupied by transactions for a period of time exceeding a preset time threshold.

[0280] Based on the specific reasons, a solution is determined, which includes terminating low-priority transactions, releasing resources that have been occupied for more than a preset time threshold, or adjusting the execution priority of transactions.

[0281] Generate an analysis report, which includes detailed information on transaction nodes and resource nodes, a dependency chain diagram, deadlock cause analysis, and solutions.

[0282] In one embodiment, the analysis report generation module 80 is specifically used for:

[0283] The analysis report is sent to the management module via the message notification module;

[0284] The management module displays the execution options for the solution in the analysis report through a user interface. These execution options include terminating the transaction or releasing resources.

[0285] The user interface receives the selection information of the execution option and executes the corresponding solution operation according to the selection information.

[0286] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and 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 network interface is used for communication with external user terminals via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a database deadlock detection and analysis method on the server side.

[0287] In one embodiment, a computer device is provided, which may be a user terminal, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a database deadlock detection and analysis method on the user side.

[0288] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps:

[0289] Load the configuration file of the deadlock detection module, and extract the monitoring interval parameter and log level parameter from the configuration file;

[0290] Connect to the target database based on the target database information in the configuration file;

[0291] Based on the monitoring interval parameter, the status information of transactions and resources in the target database is periodically obtained through the database application interface, and the status information of transactions and resources is stored as a status snapshot;

[0292] Based on the state snapshot, initialize the data structure of the resource wait graph;

[0293] Based on the transaction identifier, resource identifier, and the request and occupancy relationship of the transaction to the resource contained in the state snapshot, add transaction nodes, resource nodes, request edges, and occupancy edges to the resource waiting graph;

[0294] A depth-first search traversal is performed on all nodes in the resource waiting graph to detect whether there are cycles in the resource waiting graph;

[0295] If a loop is detected in the resource waiting graph, it is determined that the transactions and resources involved in the loop constitute a deadlock, and the information of the transaction nodes and resource nodes in the loop, the occupancy relationship between the transaction nodes and resource nodes, and the waiting relationship between the transaction nodes are recorded.

[0296] Based on the status information of the transactions, the status information of the resources, the information of the transaction nodes and resource nodes in the loop, the occupancy relationship between the transaction nodes and resource nodes, and the waiting relationship between the transaction nodes, an analysis report containing deadlock cause analysis and solutions is generated.

[0297] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0298] Load the configuration file of the deadlock detection module, and extract the monitoring interval parameter and log level parameter from the configuration file;

[0299] Connect to the target database based on the target database information in the configuration file;

[0300] Based on the monitoring interval parameter, the status information of transactions and resources in the target database is periodically obtained through the database application interface, and the status information of transactions and resources is stored as a status snapshot;

[0301] Based on the state snapshot, initialize the data structure of the resource wait graph;

[0302] Based on the transaction identifier, resource identifier, and the request and occupancy relationship of the transaction to the resource contained in the state snapshot, add transaction nodes, resource nodes, request edges, and occupancy edges to the resource waiting graph;

[0303] A depth-first search traversal is performed on all nodes in the resource waiting graph to detect whether there are cycles in the resource waiting graph;

[0304] If a loop is detected in the resource waiting graph, it is determined that the transactions and resources involved in the loop constitute a deadlock, and the information of the transaction nodes and resource nodes in the loop, the occupancy relationship between the transaction nodes and resource nodes, and the waiting relationship between the transaction nodes are recorded.

[0305] Based on the status information of the transactions, the status information of the resources, the information of the transaction nodes and resource nodes in the loop, the occupancy relationship between the transaction nodes and resource nodes, and the waiting relationship between the transaction nodes, an analysis report containing deadlock cause analysis and solutions is generated.

[0306] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and user side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0307] Those skilled in the art will understand that all or part of the processes in the methods of 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, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0308] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0309] It should be noted that if any software tools or components not belonging to this company appear in the embodiments of this application, they are merely illustrative examples and do not represent actual use. The embodiments described above are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.< / database> < / port> < / host> < / database> < / port> < / host>

Claims

1. A database deadlock detection and analysis method, characterized in that, Includes the following steps: Load the configuration file of the deadlock detection module, and extract the monitoring interval parameter and log level parameter from the configuration file; Connect to the target database based on the target database information in the configuration file; Based on the monitoring interval parameter, the status information of transactions and resources in the target database is periodically obtained through the database application interface, and the status information of transactions and resources is stored as a status snapshot; Based on the state snapshot, initialize the data structure of the resource wait graph; Based on the transaction identifier, resource identifier, and the request and occupancy relationship of the transaction to the resource contained in the state snapshot, add transaction nodes, resource nodes, request edges, and occupancy edges to the resource waiting graph; A depth-first search traversal is performed on all nodes in the resource waiting graph to detect whether there are cycles in the resource waiting graph; If a loop is detected in the resource waiting graph, it is determined that the transactions and resources involved in the loop constitute a deadlock, and the information of the transaction nodes and resource nodes in the loop, the occupancy relationship between the transaction nodes and resource nodes, and the waiting relationship between the transaction nodes are recorded. Based on the status information of the transactions, the status information of the resources, the information of the transaction nodes and resource nodes in the loop, the occupancy relationship between the transaction nodes and resource nodes, and the waiting relationship between the transaction nodes, an analysis report containing deadlock cause analysis and solutions is generated.

2. The database deadlock detection and analysis method as described in claim 1, characterized in that, Based on the state snapshot, initialize the data structure of the resource wait graph, including: Choose a data structure for the resource waiting graph and use an adjacency list or adjacency matrix as the representation method for the resource waiting graph; Based on the number of transaction identifiers and resource identifiers in the state snapshot, allocate storage space for the information of transaction nodes and resource nodes in the resource wait graph, and initialize the storage structure of transaction nodes and resource nodes. Create a mapping table between the transaction nodes and resource nodes. The mapping table is used to record the mapping relationship between the transaction identifier and the resource identifier to the corresponding node index in the resource wait graph. Based on the log level parameters, record detailed information about the resource waiting graph initialization process, including data structure type, number of nodes, and storage space size.

3. The database deadlock detection and analysis method as described in claim 1, characterized in that, Based on the transaction identifiers, resource identifiers, and the request and occupancy relationships of transactions to resources contained in the state snapshot, transaction nodes, resource nodes, request edges, and occupancy edges are added to the resource waiting graph, including: Iterate through all transaction identifiers and resource identifiers recorded in the state snapshot, and read the transaction's request relationship to the resource and the resource's occupation relationship to the transaction one by one; Check the node set of the resource wait graph to confirm whether the node set contains all transaction identifiers and resource identifiers; If there are any unincluded transaction identifiers or resource identifiers, then create a transaction node corresponding to the transaction identifier or a resource node corresponding to the resource identifier, and add the transaction node or resource node to the node set of the resource waiting graph. Based on the resource request relationship of the transaction, add request edges from the transaction node to the resource node in the resource waiting graph, and record the type and relationship of the request edges in the edge storage structure of the resource waiting graph; Based on the resource-transaction occupancy relationship, an occupancy edge pointing from the resource node to the transaction node is added to the resource waiting graph, and the type and relationship of the occupancy edge are recorded in the edge storage structure of the resource waiting graph.

4. The database deadlock detection and analysis method as described in claim 1, characterized in that, A depth-first search traversal is performed on all nodes in the resource waiting graph to detect whether a cycle exists in the resource waiting graph, including: Initialize the state of all nodes in the resource waiting graph to unvisited, and set up a recursive stack to record node information of the current path; Select an unvisited node from the resource waiting graph as the starting node, and perform a depth-first search traversal recursively. During the depth-first search process, the current node is marked as being visited, and the connected nodes connected to the current node are visited in turn. If a connected node is detected to already exist in the recursion stack, it is determined that a loop exists. When all connected nodes of the current node have been visited, the current node is marked as visited and removed from the recursion stack.

5. The database deadlock detection and analysis method as described in claim 1, characterized in that, If a loop is detected in the resource wait graph, after determining that the transactions and resources involved in the loop constitute a deadlock, the process further includes: At least one transaction is terminated based on transaction priority or scope of impact to resolve the deadlock; Perform a rollback operation on the terminated transaction to release the occupied resources and restore the target database to its normal state; The log level parameters are used to record information about transaction termination and rollback operations during the deadlock resolution process.

6. The database deadlock detection and analysis method as described in claim 1, characterized in that, Based on the transaction status information, resource status information, information about transaction nodes and resource nodes in the loop, the occupancy relationships between transaction nodes and resource nodes, and the waiting relationships between transaction nodes, an analysis report containing deadlock cause analysis and solutions is generated, including: The transaction status information, resource status information, information on transaction nodes and resource nodes in the loop, and the occupancy and waiting relationships between transaction nodes and resource nodes are integrated to construct a dependency link graph between transactions and resources. Based on the dependency chain graph, the interaction path between transactions and resources is analyzed to determine the specific reasons for deadlock formation. The specific reasons include circular dependencies between transactions or resources being occupied by transactions for a period of time exceeding a preset time threshold. Based on the specific reasons, a solution is determined, which includes terminating low-priority transactions, releasing resources that have been occupied for more than a preset time threshold, or adjusting the execution priority of transactions. Generate an analysis report, which includes detailed information on transaction nodes and resource nodes, a dependency chain diagram, deadlock cause analysis, and solutions.

7. The database deadlock detection and analysis method as described in claim 1, characterized in that, Based on the transaction status information, resource status information, and information about transaction nodes and resource nodes in the loop, as well as the occupancy and waiting relationships between transaction nodes and resource nodes, after generating an analysis report containing deadlock cause analysis and solutions, it also includes: The analysis report is sent to the management module via the message notification module; The management module displays the execution options for the solution in the analysis report through a user interface. These execution options include terminating the transaction or releasing resources. The user interface receives the selection information of the execution option and executes the corresponding solution operation according to the selection information.

8. A database deadlock detection and analysis device, characterized in that, The database deadlock detection and analysis device includes: The configuration management module is used to load the configuration file of the deadlock detection module and extract the monitoring interval parameter and log level parameter from the configuration file. The database connection module is used to connect to the target database according to the target database information in the configuration file; The data acquisition module is used to periodically acquire the status information of transactions and resources in the target database through the database application interface according to the monitoring interval parameter, and store the status information of transactions and resources as a status snapshot; The graph data initialization module is used to initialize the data structure of the resource wait graph based on the state snapshot. The graph construction module is used to add transaction nodes, resource nodes, request edges, and occupy edges to the resource waiting graph based on the transaction identifier, resource identifier, and the request and occupancy relationship of the transaction to the resource contained in the state snapshot. The loop detection module is used to perform a depth-first search traversal of all nodes in the resource waiting graph to detect whether there is a loop in the resource waiting graph; The deadlock determination module is used to determine that the transactions and resources involved in the loop constitute a deadlock if a loop is detected in the resource waiting graph, and to record the information of the transaction nodes and resource nodes in the loop, the occupancy relationship between the transaction nodes and resource nodes, and the waiting relationship between the transaction nodes. The analysis report generation module is used to generate an analysis report containing deadlock cause analysis and solutions based on the status information of the transaction, the status information of the resource, the information of the transaction nodes and resource nodes in the loop, the occupancy relationship between the transaction nodes and resource nodes, and the waiting relationship between the transaction nodes.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a database deadlock detection and analysis program stored in the memory and executable on the processor. When the database deadlock detection and analysis program is executed by the processor, it implements the steps of the database deadlock detection and analysis method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a database deadlock detection and analysis program, which, when executed by a processor, implements the steps of the database deadlock detection and analysis method as described in any one of claims 1-7.

Images