Method, medium, product and device for session connection management during database replay

Abstract

This invention provides a method, medium, product, and device for session connection management during database playback. The method includes: receiving a session identifier from a session during playback; generating an allocation identifier based on the low-order byte of the session identifier; determining a target pointer array corresponding to the session in a pre-set session management table based on the allocation identifier, wherein the session management table pre-sets a predetermined number of pointer arrays, each pointer array corresponding to a singly linked list and pointing to the head node of the corresponding singly linked list; determining whether a target node matching the session identifier exists in the target singly linked list corresponding to the target pointer array; if no target node exists in the target singly linked list, creating a new connection node and inserting the new connection node into the target singly linked list. This method enables rapid generation of the allocation identifier based on the low-order byte, and achieves rapid location and efficient storage of session nodes using a singly linked list structure, ensuring the stability and smoothness of high-concurrency playback processes.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a method, medium, product, and device for managing session connections during database playback. Background Technology

[0002] Currently, with the deepening of the domestic IT innovation strategy, key industries such as finance and telecommunications are accelerating the localization of databases to reduce their dependence on foreign products such as Oracle, MySQL, and SQL Server. Heterogeneous database replay technology, as a key means of verifying the performance and compatibility of domestic databases, captures the real load of the source production database, replays it on the target domestic database, and compares the results to effectively evaluate the performance of the migrated system. In this process, accurately simulating the session behavior of the source database is the core prerequisite for ensuring the authenticity of the replay, because database operations (such as SQL execution and transaction processing) are closely related to specific session contexts.

[0003] In heterogeneous database playback systems, the session management module is responsible for maintaining the session connection information captured by the source database, so that subsequent operations can be associated with the correct session during playback. Traditional session management methods typically use data structures such as singly linked lists, hash tables, or red-black trees, storing and retrieving data using session identifiers (such as session_id) as keys. However, these methods do not fully consider the unique requirements of the playback scenario: on the one hand, the playback process needs to handle a large number of concurrent sessions, which may reach tens of thousands or even hundreds of thousands, placing extremely high demands on search efficiency; on the other hand, the session IDs generated by the source database often have specific distribution patterns. For example, in databases such as MySQL and PostgreSQL, session IDs may be related to thread IDs or process IDs, and their low-byte distribution is relatively uniform.

[0004] Existing technologies often employ general-purpose hash functions (such as modulo operations) when processing session IDs. While these functions achieve basic functionality, they suffer from the following drawbacks: First, general-purpose hash functions have significant computational overhead, potentially becoming a performance bottleneck under high-throughput playback loads. Second, without optimization for the distribution characteristics of session IDs, severe hash collisions may occur, leading to excessively long collision chains and a sharp decline in lookup efficiency. Furthermore, some implementations use dynamically expanding hash tables, which, while reducing collisions, increase the complexity of memory management and concurrency control, making them unsuitable for the simplicity and efficiency goals of playback systems. More importantly, existing solutions often neglect session lifecycle management during playback, failing to provide efficient insertion and deletion operations, resulting in unnecessary waiting during session switching during playback. Summary of the Invention

[0005] In view of the above problems, the present invention proposes a method, medium, product and device for session connection management during database playback that overcomes or at least partially solves the above problems.

[0006] One objective of this invention is to provide an efficient and reliable session management mechanism for heterogeneous database playback, thereby improving the overall performance and authenticity of the playback system.

[0007] A further objective of this invention is to achieve rapid location and conflict resolution of session connections.

[0008] Specifically, the present invention provides a session connection management method during database playback, comprising: The session identifier during playback; The allocation identifier is generated based on the low-order byte of the session identifier, which is set in terms of the number of bits. The target pointer array corresponding to the session is determined according to the allocation identifier in the preset session management table. The session management table has a set number of pointer arrays in advance. Each pointer array corresponds to a singly linked list and points to the head node of the corresponding singly linked list. Determine if a target node matching the session identifier exists in the target singly linked list corresponding to the target pointer array; If the target node does not exist in the target singly linked list, create a new connection node and insert the new connection node into the target singly linked list.

[0009] Optionally, it also includes: In response to a deletion command for a session to be deleted, calculate the assignment identifier to be deleted corresponding to the session to be deleted; In the session management table, determine the array of pointers to be operated on corresponding to the session to be deleted based on the assignment identifier to be deleted; Remove the session to be deleted from the singly linked list corresponding to the array of pointers to be operated on; Clean up the prepared statement resources involved in the session to be deleted and release the node memory of the corresponding node.

[0010] Optionally, the step of removing the session to be deleted from the singly linked list corresponding to the array of pointers to be operated on further includes: Traverse the singly linked list to be operated on to determine the node to be deleted corresponding to the session to be deleted; Determine whether the node to be deleted is the head node of the singly linked list to be operated on; If the node to be deleted is the head node of the singly linked list to be operated on, update the pointers of the pointer array to be operated on; If the node to be deleted is not the head node of the linked list to be operated on, modify the successor pointer of the predecessor node of the node to be deleted in the linked list to make the successor pointer point to the next node of the node to be deleted.

[0011] Optionally, after determining whether a target node matching the session identifier exists in the target singly linked list corresponding to the target pointer array, the method further includes: If the target node exists in the target singly linked list, return the pointer to the corresponding target node to complete the session query.

[0012] Optionally, the step of inserting the new connection node into the target singly linked list includes: inserting the new connection node into the head of the target singly linked list using the head insertion method; Set the successor pointer of the new connected node to the current head node of the target singly linked list, and update the pointers in the target pointer array to point to the new connected node.

[0013] Optionally, the session management table is initialized when the system starts up, and the nodes are stored based on a pointer array of fixed capacity; The allocation identifier is a hash value; The steps for generating an allocation identifier based on the low-order byte of the session identifier include: determining the numeric type of the session identifier and determining the set number of bits for the low-order byte based on the numeric type.

[0014] Optionally, the step of generating the allocation identifier based on the low-order byte of the session identifier with a set number of bits further includes: if the number type of the session identifier is a 64-bit unsigned integer, extracting its low 8-bit byte as the allocation identifier through bitwise operations. With the allocation identifier set to the lower 8 bits, the number of pointer arrays pre-set in the session management table is 256.

[0015] According to another aspect of the present invention, a computer-readable storage medium is also provided, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps of the session connection management method in the database playback process described above.

[0016] According to another aspect of the present invention, a computer program product is also provided, comprising a computer program that, when executed by a processor, implements the steps of the session connection management method during database playback as described above.

[0017] According to another aspect of the present invention, a computer device is also provided, including a memory, a processor, and a machine-executable program stored in the memory and running on the processor, wherein the processor executes the machine-executable program to implement the steps of the session connection management method in the database playback process described above.

[0018] The session connection management method during database playback of the present invention, after receiving the session identifier of the session during playback, first generates an allocation identifier based on the low-order byte of the session identifier. Then, it determines the target pointer array corresponding to the session in a preset session management table based on the allocation identifier. The session management table pre-sets a predetermined number of pointer arrays, each corresponding to a singly linked list and pointing to the head node of the corresponding singly linked list. Subsequently, it checks whether a target node matching the session identifier exists in the target singly linked list corresponding to the target pointer array. If no target node exists in the target singly linked list, a new connection node is created and inserted into the target singly linked list. This method enables rapid generation of the allocation identifier based on the low-order byte, and achieves rapid location and efficient storage of session nodes using a static pointer array and singly linked list structure. This reduces the computational overhead of session lookup and insertion, improves the response speed and processing efficiency of session management during database playback, and ensures the stability and smoothness of system operation in high-concurrency playback scenarios.

[0019] Furthermore, in the session connection management method during database playback of the present invention, when the session identifier is a 64-bit unsigned integer, the lower 8 bits of the session identifier are extracted as an allocation identifier through bitwise operations; when the allocation identifier is the lower 8 bits, the number of pointer arrays pre-set in the session management table is 256. This method enables a one-to-one index relationship between the allocation identifier and the number of pointer arrays, achieving direct and fast addressing from hash value to hash bucket, significantly improving session location efficiency; at the same time, by utilizing the uniform distribution of the lower 8 bits, session nodes are evenly distributed across the linked lists, effectively reducing the probability of hash collisions and ensuring stable and efficient session management in high-concurrency playback scenarios.

[0020] The above and other objects, advantages and features of the present invention will become more apparent to those skilled in the art from the following detailed description of specific embodiments of the invention in conjunction with the accompanying drawings. Attached Figure Description

[0021] The following sections will describe some specific embodiments of the invention in detail by way of example and not limitation, with reference to the accompanying drawings. The same reference numerals in the drawings denote the same or similar parts or portions. Those skilled in the art should understand that these drawings are not necessarily drawn to scale. In the drawings: Figure 1 This is a flowchart illustrating a session connection management method during database playback according to an embodiment of the present invention. Figure 2 This is a flowchart illustrating a session connection management method during database playback according to another embodiment of the present invention; Figure 3 This is a schematic diagram of a computer program product according to an embodiment of the present invention; Figure 4 This is a schematic diagram of a computer-readable storage medium according to an embodiment of the present invention; and Figure 5 This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0022] Those skilled in the art should understand that the embodiments described below are merely a part of the embodiments of the present invention, and not all of the embodiments of the present invention. These partial embodiments are intended to explain the technical principles of the present invention and are not intended to limit the scope of protection of the present invention. Based on the embodiments provided by the present invention, all other embodiments obtained by those skilled in the art without creative effort should still fall within the scope of protection of the present invention.

[0023] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0024] Currently, with the deepening of the domestic IT innovation strategy, key industries such as finance and telecommunications are accelerating the localization of databases to reduce their dependence on foreign products such as Oracle, MySQL, and SQL Server. Heterogeneous database replay technology, as a key means of verifying the performance and compatibility of domestic databases, captures the real load of the source production database, replays it on the target domestic database, and compares the results to effectively evaluate the performance of the migrated system. In this process, accurately simulating the session behavior of the source database is the core prerequisite for ensuring the authenticity of the replay, because database operations (such as SQL execution and transaction processing) are closely related to specific session contexts.

[0025] In heterogeneous database replay systems, session management is crucial for ensuring that replay operations are accurately linked to the source session context. The replay process handles a massive number of concurrent sessions, and each session's lifecycle may involve numerous SQL operations. Therefore, the efficiency of session connection lookup, insertion, and deletion directly impacts the overall throughput and latency of the replay. Existing session management technologies have the following main shortcomings: First, traditional implementations commonly use generic hash functions (such as modulo operations) or balanced tree structures (such as red-black trees) to index the session identifier (session_id). Generic hash functions have high computational overhead and are not optimized for the distribution characteristics of session IDs. For example, in databases such as MySQL, session IDs are often associated with thread IDs or process PIDs, with the low bytes exhibiting good randomness, while the high bytes may have a high degree of repetition. Directly taking the modulo of the complete 64-bit session ID is not only computationally expensive but may also exacerbate hash collisions due to uneven distribution, resulting in excessively long collision chains. This degenerates the search into a linear scan, severely reducing replay efficiency.

[0026] Secondly, existing solutions often employ dynamically expanding hash tables to reduce conflicts, such as scaling up and rehashing as the number of sessions increases. In high-throughput scenarios like replay, this mechanism introduces unpredictable latency due to frequent memory allocation and data migration, and the complexity of concurrency control increases the difficulty of system implementation and potential lock contention, which is detrimental to the stable execution of the replay thread.

[0027] Third, existing session management lacks optimizations for insertion and deletion in playback scenarios. During playback, session creation and closure occur frequently. If insertion uses tail insertion or fails to utilize the locality of the linked list, deletion requires traversing to find the predecessor node, further exacerbating performance overhead. In addition, traditional methods may not release related resources (such as preprocessing statements) in a timely manner during deletion, causing memory leaks and affecting the long-term stability of the system.

[0028] In summary, existing technologies struggle to provide fast, stable, and resource-efficient session connection management under the high concurrency and high throughput requirements of heterogeneous database replay. To address these issues, this invention proposes a method and apparatus for fast session connection lookup and conflict resolution in heterogeneous database replay. This design fully considers the distribution characteristics of session IDs, achieving a uniform hash distribution with minimal computational cost, significantly reducing the probability of conflicts; it also improves operational efficiency in concurrent replay scenarios. This invention provides an efficient and reliable session management mechanism for heterogeneous database replay, contributing to improved overall performance and realism of the replay system.

[0029] Specifically, the present invention provides a method for managing session connections during database playback. Figure 1 This is a flowchart illustrating a session connection management method during database playback according to an embodiment of the present invention, as shown below. Figure 1 As shown, the session connection management method during the database replay process includes at least the following steps S101 to S105.

[0030] Step S101: Receive the session identifier during the playback process. The session identifier uniquely identifies a database session during playback, enabling session context association and management, and ensuring consistency between the playback operation and the source database session behavior. Examples include a 64-bit identifier associated with a thread ID in MySQL or a 64-bit identifier associated with a process ID in PostgreSQL. These source database-generated session IDs often exhibit specific distribution patterns. For instance, in databases like MySQL and PostgreSQL, the session ID may be associated with a thread ID or process ID, possessing a uniformly distributed low-order byte distribution, making them suitable for high-concurrency heterogeneous database playback scenarios.

[0031] Step S102: Generate an allocation identifier based on the low-order byte of the session identifier with a specified number of bits. The allocation identifier is generally a hash value. The step of generating the allocation identifier based on the low-order byte of the session identifier includes: determining the numeric type of the session identifier and determining the specified number of bits for the low-order byte based on the numeric type. Using the low-order byte to generate the grouped index can adapt to the numerical structure of different database session identifiers, achieving flexible adaptation; at the same time, leveraging the inherent characteristic of the uniform distribution of the low-order bytes of the database session identifier, it achieves uniform session distribution, effectively reducing session aggregation and retrieval conflicts, and improving management efficiency.

[0032] In some optional embodiments, when the session identifier is a 64-bit unsigned integer, its lower 8 bits are extracted as the allocation identifier through bitwise operations. Bitwise operations are characterized by extremely low computational cost and extremely fast execution speed; for example, bitwise AND operations can complete hash calculations with minimal computational overhead. The lower 8 bits have a fixed and evenly distributed value range, enabling stable and efficient session grouping, which is particularly suitable for high-concurrency database playback scenarios.

[0033] Step S103: Determine the target pointer array corresponding to the session in the preset session management table based on the allocation identifier. The session management table pre-sets a predetermined number of pointer arrays, each corresponding to a singly linked list and pointing to the head node of the corresponding linked list. The session management table is initialized once during system startup, using pointer arrays of fixed capacity for storage nodes. This fixed-capacity static array structure remains unchanged during operation, eliminating the need for dynamic expansion, simplifying memory management and concurrency control, avoiding runtime latency fluctuations, and ensuring stable and efficient playback. The one-to-one correspondence between pointer arrays and singly linked lists enables session grouping and isolation, improving concurrent processing capabilities.

[0034] Optionally, when the allocation identifier is the lower 8 bits, the number of pointer arrays pre-set in the session management table is 256. The value range of the lower 8 bits corresponds one-to-one with the 256 pointer arrays, allowing direct addressing and location using the allocation identifier as the array index without additional calculations. This enables extremely fast session location, significantly shortening the session lookup path and processing time.

[0035] Step S104: Determine whether a target node matching the session identifier exists in the target singly linked list corresponding to the target pointer array. This step only performs a complete session identifier comparison within the singly linked list corresponding to the target group, eliminating the need for global traversal, significantly narrowing the search scope, reducing comparison overhead, and ensuring the speed and accuracy of session matching in high-concurrency scenarios.

[0036] Step S105: If the determination in step S104 is negative, a new connection node is created and inserted into the target singly linked list. The newly created node completes the registration and storage of the new session, saving complete session information and providing stable session context support for subsequent SQL execution, transaction processing, and other replay operations, ensuring that the replay behavior is consistent with the source.

[0037] In some optional embodiments, the step of inserting a new connection node into the target singly linked list generally includes: inserting the new connection node into the head of the target singly linked list using head insertion; setting the successor pointer of the new connection node to the current head node of the target singly linked list; and updating the pointers in the target pointer array to point to the new connection node. Since head insertion can complete the insertion without traversing the linked list, it achieves optimal insertion efficiency. Simultaneously, placing the new session at the head of the linked list adapts to the high-frequency access characteristics of new sessions, effectively improving the speed of subsequent session lookups and optimizing overall access performance.

[0038] Optionally, if the target node exists in the target singly linked list, the node pointer of the corresponding target node is returned, thereby completing the session query. The session context information can be quickly retrieved through the node pointer, enabling precise binding between the replay operation and the corresponding session. This ensures that all database operations are executed in the correct session environment, guaranteeing the authenticity, accuracy, and consistency of the replay results.

[0039] This method enables rapid session grouping with minimal hash calculations, and combines static arrays and singly linked list structures to achieve efficient session lookup, insertion, and management. It reduces system computing power and processing latency, ensures uniform session distribution and efficient retrieval, and significantly improves session management efficiency and system stability in high-concurrency replay scenarios of heterogeneous databases.

[0040] In addition, when a session needs to be deleted after playback, in response to the deletion command for the session to be deleted, the system calculates the allocation identifier for the session to be deleted; determines the array of pointers to be operated on for the session to be deleted in the session management table based on the allocation identifier; removes the session to be deleted from the singly linked list of pointers to be operated on; cleans up the preprocessed statement resources involved in the session to be deleted and releases the node memory of the corresponding nodes. This process enables closed-loop management of the entire session lifecycle, promptly removing invalid nodes and releasing associated resources after the session is used, avoiding resource occupation and memory leaks, ensuring efficient reuse of system resources, and improving the long-term stability and reliability of the system.

[0041] Optionally, the step of removing the session to be deleted from the linked list corresponding to the pointer array further includes: traversing the linked list to determine the node to be deleted corresponding to the session; determining whether the node to be deleted is the head node of the linked list; if the node to be deleted is the head node, updating the pointers in the pointer array; if the node to be deleted is not the head node, modifying the successor pointer of the predecessor node of the node to be deleted in the linked list so that the successor pointer points to the next node of the node to be deleted. This method synchronously completes node lookup and predecessor node recording in a single traversal, supporting removal of both head and non-head nodes in all scenarios. It eliminates the need for secondary traversal to adjust the linked list pointers, simplifying the deletion logic, improving deletion efficiency, and adapting to the business needs of frequent session destruction in high-concurrency scenarios.

[0042] Figure 2 This is a flowchart illustrating a session connection management method during database playback according to another embodiment of the present invention, as shown below. Figure 2 As shown, the process includes at least the following steps S201 to S212.

[0043] Step S201: Receive the session identifier of the session during playback. This step is used to collect the unique identification information of each session in the database playback link, serving as the index basis for session lifecycle management, ensuring that different sessions are independent and do not interfere with each other, and laying the data foundation for subsequent accurate addressing and context binding.

[0044] Step S202: Generate an allocation identifier based on the low-order byte of the number of bits set in the session identifier.

[0045] Since session IDs generated by the source database often exhibit specific distribution patterns—for example, in databases like MySQL and PostgreSQL, session IDs may be related to thread IDs or process IDs, and their low-byte distribution is relatively uniform—this step generates a grouped index based on the inherent characteristic of the uniform distribution of low-byte segments in database session identifiers. A lightweight computational method is used to perform session routing, replacing traditional complex hash algorithms, effectively reducing computational consumption, and simultaneously achieving a uniform distribution of sessions in the storage structure, thus reducing retrieval conflicts.

[0046] Step S203: Determine the target pointer array corresponding to the session in the preset session management table based on the allocation identifier. This step directly completes the addressing and location of the storage unit through the allocation identifier. Relying on the pre-initialized fixed-capacity pointer array architecture, it realizes fast grouping and mapping of sessions without dynamic addressing and global retrieval, which greatly shortens the session location time and improves the response speed in high-concurrency scenarios.

[0047] Step S204: Determine if a target node matching the session identifier exists in the target singly linked list corresponding to the target pointer array. This step only performs session identifier matching verification within the singly linked list corresponding to the target group, limiting the search scope and avoiding performance overhead caused by global traversal. Precise comparison ensures the accuracy of session identification, providing a basis for subsequent branch processing.

[0048] Step S205: If the determination in step S204 is yes, return the node pointer of the corresponding target node, thereby completing the session query. Since this step quickly returns the node index when the session already exists, the session-related data can be directly retrieved through the node pointer, realizing the rapid reuse of existing sessions, simplifying the repeated creation process, and thus improving the execution efficiency and continuity of the replay process.

[0049] Step S206: If the determination in step S204 is negative, a new connection node is created and inserted into the target singly linked list. This step completes the node initialization and storage mounting for the new session, realizes the registration and management of the new session, ensures that all replay sessions can be completely recorded, and provides complete session context support for subsequent database operation replay.

[0050] Step S207: After step S204 or step S205 is completed, the session context information is determined, and subsequent replay processes are executed. This step enables deep binding between session nodes and replay services. Based on the queried or newly created session node, the corresponding context environment is loaded, ensuring that replay operations such as SQL execution and transaction processing are performed in the matching session environment. This guarantees that the replay behavior is completely consistent with the source database, improving the realism of the replay.

[0051] Step S208: After playback is complete, issue a deletion command. Upon completion of playback, the session lifecycle termination process must be triggered promptly. A destruction request should be initiated for invalid sessions that have undergone playback, enabling on-demand reclamation of session resources and preventing invalid sessions from occupying system resources for extended periods.

[0052] Step S209: In response to the deletion command of the session to be deleted, calculate the assignment identifier to be deleted corresponding to the session. By reusing the unified group index calculation rules, the storage group to which the session to be destroyed belongs can be quickly located, ensuring the logical consistency between the deletion process and the search and insertion processes, and simplifying the system architecture design.

[0053] Step S210: Determine the array of pointers to be operated on corresponding to the session to be deleted in the session management table based on the assignment identifier to be deleted. This step, by precisely locking the singly linked list storage unit where the session to be deleted is located, can achieve isolated execution of the deletion operation without affecting the normal operation of other group sessions, thus improving system stability in concurrent scenarios.

[0054] Step S211: Remove the session to be deleted from the singly linked list corresponding to the array of pointers to be operated on. Specifically, during the removal process, if it is the head node, update the pointer of the array of pointers to be operated on; otherwise, modify the next pointer of the predecessor node. This allows for efficient removal of nodes through linked list pointer adjustments, breaking the association between invalid nodes and the storage structure, and preparing for subsequent resource release.

[0055] Step S212: Clean up the prepared statement resources involved in the session to be deleted and release the node memory of the node to be deleted. This step can realize the full reclamation of session-related resources, not only releasing the memory space of the node itself, but also cleaning up the ancillary resources such as prepared statements, completely eliminating memory leak problems, realizing the cyclic reuse of system resources, and ensuring the long-term high-concurrency stable operation of the database replay system.

[0056] The session lifecycle management process of this invention achieves lightweight execution of the entire session operation process through a unified low-byte indexing mechanism, static fixed storage architecture, and single-linked list conflict handling method. At the same time, it deeply integrates session context binding and resource linkage recycling, which improves the efficiency of session search, insertion, and deletion while ensuring the accuracy of replay data and the efficient utilization of system resources. It effectively adapts to the high-concurrency and high-throughput replay business requirements in the migration of heterogeneous databases to domestic systems, and significantly improves the overall performance and operational reliability of the system.

[0057] To more clearly illustrate the method of the present invention, a preferred embodiment is provided, the core steps of which include: Step 1: Hash value calculation: When a session ID (of type uint64_t) is received, its lower 8 bits are first extracted as a hash value using the macro definition hash_session(x), i.e., (unsigned char)(x & 0xFF). This operation requires only one bitwise AND operation, making it extremely efficient. Since the lower bytes of the session ID typically have good randomness, this hash function can evenly distribute a large number of sessions across 256 buckets, effectively reducing the probability of collisions.

[0058] Step 2: Initialize the hash table: When the system starts, a static pointer array hash_conn

[256] of size 256 is pre-allocated, and all elements are initialized to NULL. This array serves as a hash bucket, with each bucket pointing to the head node of the corresponding linked list. Using a fixed size avoids the complexity of memory management and concurrency control caused by dynamic expansion, making it suitable for high-throughput playback scenarios.

[0059] Step 3: Find the link: Given a session ID, first calculate its hash value, then locate the corresponding bucket hash_conn[hash]. Traverse the singly linked list pointed to by the bucket, comparing the session_id field of each node in turn. If a match is found, return the pointer to that node; if no match is found after traversing to the end of the linked list, it means that the session does not currently exist. The search operation only requires traversing the linked list within a single bucket. Due to the uniform hash distribution, the linked list length is usually very short, and the search time complexity is close to O(1).

[0060] Step 4: Insert a new connection: When a new session event is encountered during playback, the corresponding connection needs to be inserted into the hash table. First, a lookup operation is performed to confirm that the session does not exist. Then, a new connection node conn is created, memory is allocated for it, and fields such as session_id and statements (head of the preprocessed statement list) are initialized. The head insertion method is used to insert the new node into the head of the linked list of the corresponding bucket. The head insertion method does not require traversing the linked list, and the insertion time complexity is O(1). Moreover, newly established sessions are more likely to be accessed frequently, and being located at the head of the linked list can speed up subsequent lookups.

[0061] Step 5: Delete the link: When a session ends, the corresponding connection needs to be removed from the hash table. First, the hash value is calculated. Then, the linked list of the corresponding bucket is traversed, recording the pointer to the predecessor node. Once the target node is found, it is removed from the linked list (if it's the head node, the bucket pointer is updated; otherwise, the predecessor node's next pointer is modified). Related resources are then called to clean up and release all preprocessing statement resources associated with the session. Finally, the node's memory is released. The deletion operation also only requires traversing a single bucket, and the use of the predecessor pointer avoids a second traversal, resulting in high efficiency.

[0062] Step Six: Conflict Resolution and Linked List Maintenance Since hash functions may map different session IDs to the same bucket, this invention uses a singly linked list to resolve collisions. All nodes mapped to the same bucket are dynamically linked using head insertion to form a linked list. This linked list does not require sorting and is traversed linearly during lookups. Because the number of hash buckets is fixed at 256 and the low-byte distribution of session IDs is uniform, the linked list length is controllable (the average linked list length is approximately the total number of sessions / 256). Even with tens of thousands of concurrent sessions, the lookup overhead remains acceptable, fully meeting the high-performance requirements of the playback system.

[0063] Through the above steps, this invention achieves rapid management of massive session connections during heterogeneous database playback, thereby effectively reducing hash calculation and lookup overhead, simplifying memory management, and improving the overall throughput and stability of the playback system.

[0064] The flowchart provided in this embodiment is not intended to indicate that the operations of the method will be performed in any particular order, or that all operations of the method are included in every case. Furthermore, the method may include additional operations. Within the scope of the technical concept provided by the method in this embodiment, additional variations can be made to the above method.

[0065] It should be understood that in some embodiments, the components may be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods may be implemented using software or firmware stored in memory and executed by a suitable instruction execution system.

[0066] This embodiment also provides a computer program product 10, a computer-readable storage medium 20, and a computer device 30. Figure 3 This is a schematic diagram of a computer program product 10 according to an embodiment of the present invention. Figure 4 This is a schematic diagram of a computer-readable storage medium 20 according to an embodiment of the present invention. Figure 5 This is a schematic diagram of a computer device 30 according to an embodiment of the present invention. The computer program product 10 includes a computer program 11, which, when executed by the processor 32, implements the steps of the session connection management method during database playback as described above. A computer-readable storage medium 20 stores the computer program 11 thereon, which, when executed by the processor 32, implements the steps of the session connection management method during database playback as described above. The computer device 30 may include a memory 31, a processor 32, and the computer program 11 stored on the memory 31 and running on the processor 32.

[0067] The computer program 11 used to perform the operations of this invention may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages ​​and procedural programming languages. The computer program 11 may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a Local Area Network (LAN) or Wide Area Network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, to perform aspects of this invention, electronic circuits, including, for example, programmable logic circuits, Field-Programmable Gate Arrays (FPGAs), or Programmable Logic Arrays (PLAs), may execute computer-readable program instructions to personalize the electronic circuits by utilizing state information from computer-readable program instructions.

[0068] For the purposes of this embodiment, computer program product 10 is a related product containing computer program 11. For the purposes of this embodiment, computer-readable storage medium 20 is a tangible device capable of holding and storing computer program 11, and can be any device capable of containing, storing, communicating, propagating, or transmitting program 11 for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable storage medium 20 include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanical encoding device, and any suitable combination thereof.

[0069] Computer device 30 can be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, computer device 30 can be a cloud computing node. Computer device 30 can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. Computer device 30 can be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can reside on local or remote computing system storage media, including storage devices.

[0070] Computer device 30 may include a processor 32 adapted to execute stored instructions and a memory 31 that provides temporary storage space for the operation of said instructions during operation. The processor 32 may be a single-core processor, a multi-core processor, a computing cluster, or any other configuration. The memory 31 may include random access memory (RAM), read-only memory, flash memory, or any other suitable storage system.

[0071] Computer device 30 may also include a network adapter / interface and an input / output (I / O) interface. The I / O interface allows external devices that can be connected to the computer device to input and output data. The network adapter / interface provides communication between the computer device and a network, typically represented as a communication network.

[0072] Therefore, those skilled in the art should recognize that although numerous exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications conforming to the principles of the present invention can be directly determined or derived from the disclosure of the present invention without departing from the spirit and scope of the invention. Thus, the scope of the present invention should be understood and construed as covering all such other variations or modifications.

Claims

1. A method for managing session connections during database playback, comprising: The session identifier of the session received during playback; An allocation identifier is generated based on the low-order byte of the session identifier, which is set to a certain number of bits. The target pointer array corresponding to the session is determined in the preset session management table according to the allocation identifier. The session management table is pre-set with a set number of pointer arrays, each pointer array corresponds to a singly linked list and points to the head node of the corresponding singly linked list. Determine whether a target node matching the session identifier exists in the target singly linked list corresponding to the target pointer array; If the target node does not exist in the target singly linked list, a new connection node is created and inserted into the target singly linked list.

2. The session connection management method during database playback according to claim 1, wherein, Also includes: In response to a deletion command for a session to be deleted, calculate the assignment identifier to be deleted corresponding to the session to be deleted; The array of pointers to be operated on corresponding to the session to be deleted is determined in the session management table according to the assignment identifier to be deleted. Remove the session to be deleted from the singly linked list corresponding to the array of pointers to be operated on. Clean up the preprocessed statement resources involved in the session to be deleted and release the node memory of the corresponding node.

3. The session connection management method during database playback according to claim 2, wherein, The step of removing the session to be deleted from the singly linked list corresponding to the array of pointers to be operated on further includes: Traverse the singly linked list to be operated on, thereby determining the node to be deleted corresponding to the session to be deleted; Determine whether the node to be deleted is the head node of the singly linked list to be operated on; If the node to be deleted is the head node of the singly linked list to be operated on, update the pointers of the pointer array to be operated on; If the node to be deleted is not the head node of the linked list to be operated on, modify the successor pointer of the predecessor node of the node to be deleted in the linked list to be operated on, so that the successor pointer points to the next node of the node to be deleted.

4. The session connection management method during database playback according to claim 1, wherein, After the step of determining whether a target node matching the session identifier exists in the target singly linked list corresponding to the target pointer array, the method further includes: If the target node exists in the target singly linked list, return the node pointer corresponding to the target node to complete the query of the session.

5. The session connection management method during database playback according to claim 1, wherein, The step of inserting the new connection node into the target singly linked list includes: inserting the new connection node into the head of the target singly linked list using the head insertion method; Set the successor pointer of the new connection node to the current head node of the target singly linked list, and update the pointers of the target pointer array to point to the new connection node.

6. The session connection management method during database playback according to claim 1, wherein, The session management table is initialized when the system starts up, and the nodes are stored based on a pointer array of fixed capacity; The allocation identifier is a hash value; The step of generating an allocation identifier based on the low-order byte of the session identifier with a set number of bits includes: determining the numeric type of the session identifier, and determining the set number of bits of the low-order byte based on the numeric type.

7. The session connection management method during database playback according to claim 1, wherein, The step of generating an allocation identifier based on the low-order byte of the session identifier with a set number of bits further includes: when the number type of the session identifier is a 64-bit unsigned integer, extracting its low 8 bits as the allocation identifier through bitwise operations. When the allocation identifier is the lower 8 bits, the number of pointer arrays pre-set in the session management table is 256.

8. A computer-readable storage medium having a computer program stored thereon, said computer program, when executed by a processor, implementing the steps of the session connection management method during database playback as described in any one of claims 1 to 7.

9. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the session connection management method during database playback as described in any one of claims 1 to 7.

10. A computer device comprising a memory, a processor, and a machine-executable program stored in the memory and running on the processor, wherein the processor, when executing the machine-executable program, implements the steps of the session connection management method during database playback according to any one of claims 1 to 7.

Images