Database failure message mechanism optimization method and device, equipment and storage medium

Abstract

The invention provides a database failure message mechanism optimization method and device, equipment and a storage medium, and the method comprises the steps: when a current session operates a data table or an object on the data table triggers a failure message, judging whether the data table triggering the failure message is a local temporary table created by the current session or not; if yes, storing the failure message as a first message to a first storage data structure; if the data table triggering the failure message is not the local temporary table, the failure message is stored in a second storage data structure as a second message; the first message stored in the first storage data structure is applied to the cache of the current session, the second message stored in the second storage data structure is stored in a shared failure message queue, and the shared failure message queue is used for broadcasting the second message to all sessions. According to the scheme, meaningless global broadcast of the temporary table message in the shared queue is avoided, and resource competition and communication overhead in a concurrent scene are remarkably reduced.

Description

Technical Field

[0001] The present application relates to the field of database technology, and in particular to a method, apparatus, device, and storage medium for optimizing a database invalidation message mechanism. Background Art

[0002] The Invalidate Message Mechanism is an internal mechanism used to notify other backend processes that certain cached objects have expired. When objects in the database (such as tables, views, functions, etc.) change, the program needs to ensure that all query plans and other cached data that depend on these objects are updated or recalculated to reflect the latest status. This mechanism is mainly implemented through a shared memory called the "Shared Invalidation Message Queue". Whenever an object is modified, such as created, deleted, or its structure changed, a message is added to this queue. Each backend process will periodically check this queue and clean up its local cache as needed. To ensure mutual exclusive access to the message queue, an LWLock (lightweight lock) must be set on the message queue when writing.

[0003] Temporary tables are special tables that exist during a database session and are visible only to the session that created them. Once the session ends, these temporary tables are automatically deleted. This feature makes temporary tables very suitable for storing and processing temporary data, especially in complex queries or long-running applications.

[0004] Despite the strict isolation of temporary tables (including session-level isolation of definitions and data), the existing invalidation message mechanism treats them like regular tables: any temporary table operation (such as CREATE, ALTER, and DROP) generates an invalidation message and broadcasts it to all sessions. However, because other sessions cannot access local temporary tables, broadcasting temporary table invalidation messages to all sessions is redundant. Furthermore, temporary tables are frequently created and destroyed in business (for example, to store intermediate results), causing a surge in the number of messages in the shared invalidation message queue and lock contention. With the prevalence of large-scale concurrent scenarios, frequent temporary table operations in high-concurrency scenarios require repeated locking of the shared invalidation message queue. This LWLock contention significantly increases transaction response time and reduces database system throughput. Summary of the Invention

[0005] Embodiments of the present application provide a database invalidation message mechanism optimization method, apparatus, device, and storage medium to address the technical issues in the prior art whereby any temporary table-related invalidation message is broadcast to all sessions, resulting in redundant communication, and whereby frequent temporary table operations in high-concurrency scenarios require repeated locking of a shared invalidation message queue, resulting in LWLock contention that significantly prolongs transaction response time and reduces database system throughput.

[0006] In a first aspect, the present application provides a method for optimizing a database invalidation message mechanism, the method comprising:

[0007] When an invalidation message is triggered by operating a data table or an object on a data table in the current session, it is determined whether the data table that triggered the invalidation message is a local temporary table created by the current session:

[0008] If the data table that triggers the invalidation message is the local temporary table, storing the invalidation message as the first message in the first storage data structure;

[0009] If the data table that triggers the invalidation message is not the local temporary table, storing the invalidation message as a second message in a second storage data structure;

[0010] The first message stored in the first storage data structure is applied to the cache of the current session, and the second message stored in the second storage data structure is stored in a shared invalidation message queue, which is used to broadcast the second message to all sessions.

[0011] In one possible design, determining whether the data table that triggers the invalidation message is a local temporary table created for the current session includes:

[0012] Obtaining a unique identifier in the invalidation message, where the unique identifier is used to uniquely identify a data table in a database, and indicating in the invalidation message the data table that triggers the invalidation message;

[0013] Searching whether the unique identifier in the invalidation message is stored in an index data structure, the index data structure being used to store the unique identifiers corresponding to all the local temporary tables;

[0014] If found, confirm that the data table that triggers the invalidation message is the local temporary table;

[0015] If not found, it is confirmed that the data table that triggers the invalidation message is not the local temporary table.

[0016] In one possible design, obtaining the unique identifier in the invalidation message includes:

[0017] obtaining an object identifier in the invalidation message as the unique identifier, wherein the object identifier is assigned to each data table by a database and is used to uniquely identify the data table in the database, and indicating the data table that triggers the invalidation message in the invalidation message;

[0018] The searching whether the unique identifier in the invalidation message is stored in the index data structure includes:

[0019] A search is performed to determine whether the object identifier in the invalidation message is stored in the index data structure.

[0020] In one possible design, searching whether the unique identifier in the invalidation message is stored in the index data structure includes:

[0021] A search is performed to determine whether the unique identifier in the invalidation message is stored in a hash table, the hash table serving as the index data structure for storing the unique identifiers corresponding to all the local temporary tables.

[0022] In a possible design, if the data table that triggers the invalidation message is the local temporary table, storing the invalidation message as the first message in the first storage data structure includes:

[0023] Storing the first message in a first linked list serving as the first storage data structure;

[0024] If the data table that triggers the invalidation message is not the local temporary table, storing the invalidation message as a second message in a second storage data structure includes:

[0025] The second message is stored in a second linked list serving as the second storage data structure.

[0026] In a possible design, if the data table that triggers the invalidation message is the local temporary table, storing the invalidation message as the first message in the first storage data structure includes:

[0027] storing the first message in a first circular queue serving as the first storage data structure;

[0028] If the data table that triggers the invalidation message is not the local temporary table, storing the invalidation message as a second message in a second storage data structure includes:

[0029] The second message is stored in a second circular queue as the second storage data structure.

[0030] In one possible design, when an invalidation message is triggered by operating a data table or an object on a data table in the current session, before determining whether the data table that triggered the invalidation message is a local temporary table created by the current session, the method further includes:

[0031] The index data structure is created, and whenever the current session creates the local temporary table, the unique identifier corresponding to the currently created local temporary table is stored in the index data structure, and only the current session is granted permission to access the local temporary table.

[0032] In a second aspect, the present application provides a database invalidation message mechanism optimization device, the device comprising:

[0033] The data table type determination module is used to: when an invalidation message is triggered by operating a data table or an object on a data table in the current session, determine whether the data table that triggered the invalidation message is a local temporary table created in the current session:

[0034] If the data table that triggers the invalidation message is the local temporary table, storing the invalidation message as the first message in the first storage data structure;

[0035] If the data table that triggers the invalidation message is not the local temporary table, storing the invalidation message as a second message in a second storage data structure;

[0036] An invalidation message application module is used to apply the first message stored in the first storage data structure to the cache of the current session, and store the second message stored in the second storage data structure to a shared invalidation message queue, and the shared invalidation message queue is used to broadcast the second message to all sessions.

[0037] In a third aspect, the present application provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor;

[0038] The memory stores computer-executable instructions;

[0039] The processor executes the computer-executable instructions stored in the memory to implement the database invalidation message mechanism optimization method as described in the first aspect.

[0040] In a second aspect, the present application provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are executed by a processor, they are used to implement the database invalidation message mechanism optimization method as described in the first aspect.

[0041] The database invalidation message mechanism optimization method, apparatus, device, and storage medium provided in the embodiments of the present application have the following technical effects:

[0042] When the table is a temporary table, the invalidation message is stored in the first storage data structure; when the table is a non-temporary table, it is stored in the second storage data structure. Through this mechanism, the two types of invalidation messages are diverted during the storage phase, allowing for targeted processing during the application phase. Invalidation messages for temporary tables only need to act on the cache of the current session that created the table (such as clearing table-related query plans), while invalidation messages for non-temporary tables are broadcast to all sessions via a shared queue to achieve global cache consistency. This solution isolates the propagation range of invalidation messages for temporary and non-temporary tables, avoiding the meaningless global broadcast of temporary table messages in shared queues. Ultimately, while ensuring cache invalidation accuracy, it significantly reduces resource contention and communication overhead in concurrent scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0044] Figure 1 A schematic diagram of a database failure message mechanism optimization method provided in an embodiment of the present application Figure 1 ;

[0045] Figure 2 A schematic diagram of a database failure message mechanism optimization method provided in an embodiment of the present application Figure 2 ;

[0046] Figure 3 This is a schematic diagram of the structure of the database failure message mechanism optimization device provided by this application;

[0047] Figure 4 This is a schematic diagram of the structure of the electronic device provided in this application.

[0048] The above drawings illustrate specific embodiments of the present application, which will be described in more detail below. These drawings and the textual description are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION

[0049] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0050] First, let’s explain the terms involved in this application:

[0051] Session: In a database system, a session is a logical connection instance established between a user or application and a database. Each session has its own transaction context, temporary tablespace, and cache state. In this patent, the lifecycle of a temporary table is bound to the session—a temporary table is visible only to the session that created it and is automatically destroyed when the session ends.

[0052] Invalidation message: An internal notification message generated by the system when a database object (such as a table or index) undergoes a structural change (such as a DDL operation). Invalidation messages indicate that caches that depend on the object (such as query plans and metadata caches) need to be updated or invalidated.

[0053] Shared Invalidation Message Queue: A data structure in shared memory used to store invalidation messages that need to be broadcast globally. All sessions can access this queue, but writes must be consistent using lightweight locks (LWLocks) or atomic operations.

[0054] OID (Object Identifier): A unique numeric identifier assigned to each object (such as a table, index, or function) within the database system. OIDs are persistently stored in system tables and are used to quickly locate object metadata.

[0055] Session ID: An integer value that uniquely identifies a database session, usually generated dynamically when connecting.

[0056] In view of the technical problem in the prior art that any temporary table-related invalidation message is broadcast to all sessions, resulting in redundant communication, and that frequent temporary table operations in high-concurrency scenarios require repeated locking of the shared invalidation message queue, LWLock competition significantly prolongs transaction response time, and reduces database system throughput, since this problem is caused by the fact that temporary table-related invalidation messages are stored in the shared invalidation message queue like ordinary table-related invalidation messages, the inventors consider that if temporary table-related invalidation messages and non-temporary table-related invalidation messages can be classified and processed, temporary table-related invalidation messages are no longer stored in the shared invalidation message queue and broadcast to all sessions, the above-mentioned technical problems can be solved. Therefore, the present application proposes the following technical ideas:

[0057] When an invalidation message is generated by an operation on a table or an object on a table in the current session, the system determines whether the table triggering the invalidation message is a local temporary table created for the current session. If so, the invalidation message is stored in a first storage data structure; otherwise, the invalidation message is stored in a second storage data structure. Finally, the invalidation message stored in the first storage data structure is applied to the cache of the current session, and the invalidation message stored in the second storage data structure is stored in a shared invalidation message queue. The shared invalidation message queue is used to broadcast the invalidation message stored in the queue to all sessions.

[0058] The following specific embodiments describe in detail the technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0059] Example 1

[0060] Figure 1 A schematic diagram of a database failure message mechanism optimization method provided in an embodiment of the present application Figure 1 This method can be specifically applied to the session management module in the database. The session management module may include, for example, a session controller, a metadata manager, an invalidation message processor, and a transaction coordinator. The session controller is used to create and maintain the life cycle of the session and allocate independent resources (such as memory and temporary table space) to each session; the metadata manager is used to manage the metadata of database objects (such as table names, OIDs, and permission tags); the invalidation message processor is used to process cache invalidation messages triggered by data changes (such as DDL operations); and the transaction coordinator is used to control the atomicity and consistency of transactions when they are committed. Figure 1 As shown, the method includes:

[0061] S101. When an invalidation message is triggered by operating a data table or an object on a data table in the current session, it is determined whether the data table that triggered the invalidation message is a local temporary table created in the current session:

[0062] Specifically, when the current session (the active connection between the current user or application and the database) triggers an invalidation message by operating a data table (such as drop, truncate, alter, etc.) or an object on the data table (such as an index or constraint), it is determined whether the data table that triggered the invalidation message is a local temporary table created in the current session. This can be determined, for example, by the following methods:

[0063] 1. Add a new field, relsessionid, to the database's system tables to store the session ID used to create local temporary tables. The database assigns a unique session ID when creating a session, and automatically writes the current session ID into the relsessionid field when the current session creates a local temporary table. When an operation on the target table or an object on the target table triggers an invalidation message, the target table's relsessionid is queried and compared with the current session's ID to determine whether the target table is a local temporary table. The technical advantages of this solution are the ability to directly reuse system table fields and the ability to quickly determine whether a table is a local temporary table through index optimization.

[0064] Second, a dedicated namespace for temporary tables is predefined in the database. Its OID is fixed during system initialization (for example, OID = 12345). All local temporary tables are automatically created in this dedicated namespace, and a different location cannot be specified using regular SQL. Furthermore, the relnamespace field (the OID of the namespace to which it belongs) of a local temporary table always points to the OID of the temporary table's dedicated namespace. When an invalidation message is triggered, the target table's relnamespace is checked to determine whether it is a local temporary table. This solution has the technical advantages of eliminating the need to adjust the system table structure, providing high compatibility and faster querying and locating of local temporary tables.

[0065] If the data table that triggers the invalidation message is a local temporary table, then S102, store the invalidation message as a first message in a first storage data structure;

[0066] Specifically, a dynamic array can be used as the first storage data structure to store the first message. A dynamic array is a continuous memory storage structure that can be automatically expanded and can be used to efficiently manage invalidation messages related to local temporary tables. A dynamic array can be allocated a fixed capacity (for example, 64 messages) when it is created. When the write position of the dynamic array exceeds the current capacity, it needs to be expanded to accommodate more elements. Specifically, exponential expansion can be used, such as expanding the current capacity by 2 times and implementing memory expansion through the realloc function. The dynamic array can use a subscript index (for example, current_pos) to record the latest write position. This index points to the next available insertion position. The technical advantage of using a dynamic array is that it can dynamically adapt to fluctuations in the amount of messages and avoid memory waste.

[0067] If the data table that triggers the invalidation message is not a local temporary table, then S103, store the invalidation message as a second message in a second storage data structure;

[0068] Specifically, a preallocated block chain can be used as the second storage data structure to store the second message. A preallocated block chain consists of multiple fixed-size memory blocks linked by pointers. Each block has N preallocated message slots (e.g., 32 messages per block), which can be used to batch store non-temporary table invalidation messages. The technical advantage of using a preallocated block chain is that it can submit the second message to the shared invalidation message queue in units of blocks, reducing the frequency of lock contention in high-throughput scenarios.

[0069] S104: Apply the first message stored in the first storage data structure to the cache of the current session, and store the second message stored in the second storage data structure to a shared invalidation message queue, which is used to broadcast the second message to all sessions.

[0070] Specifically, during the transaction commit phase, the first message in the dynamic array is read sequentially. Based on the message type (e.g., DROP_TABLE, ALTER_TABLE), the local cache invalidation function (e.g., InvalidateLocalCache(oid)) is called to clear or update the current session's metadata cache (e.g., system table cache, query plan cache). After the application is complete, the dynamic array write position is reset, preserving the allocated memory for subsequent reuse and avoiding duplicate allocation. Dynamic array memory can be retained until the end of the session, reducing the overhead of frequent creation and destruction.

[0071] For the second message in the pre-allocated block chain, when the transaction is committed, the head block of the pre-allocated block chain can be linked to the tail of the shared invalidation message queue (for example, this can be achieved by modifying the tail pointer through atomic operations to avoid global lock contention). Furthermore, the number of new messages can be recorded through an atomic counter to notify the background broadcast process that a new message has arrived. The background process (such as BgWorker) can traverse each block in the pre-allocated block chain, read the messages in sequence, and broadcast them to all sessions. After the broadcast is completed, the background process can recycle the idle block chain to the global memory pool for subsequent transaction reuse. At the same time, the internal messages of the block chain can be cleared or marked as overwritten to achieve block chain recycling.

[0072] The technical effects of this embodiment are as follows:

[0073] When the table is a temporary table, the invalidation message is stored in the first storage data structure; when the table is a non-temporary table, it is stored in the second storage data structure. Through this mechanism, the two types of invalidation messages are diverted during the storage phase, allowing for targeted processing during the application phase. Invalidation messages for temporary tables only need to act on the cache of the current session that created the table (such as clearing table-related query plans), while invalidation messages for non-temporary tables are broadcast to all sessions via a shared queue to achieve global cache consistency. This solution isolates the propagation range of invalidation messages for temporary and non-temporary tables, avoiding the meaningless global broadcast of temporary table messages in shared queues. Ultimately, while ensuring cache invalidation accuracy, it significantly reduces resource contention and communication overhead in concurrent scenarios.

[0074] Example 2

[0075] Figure 2 A schematic diagram of a database failure message mechanism optimization method provided in an embodiment of the present application Figure 2 ,like Figure 2 As shown, the method includes:

[0076] S201: Create an index data structure. Whenever the current session creates a local temporary table, store a unique identifier corresponding to the currently created local temporary table in the index data structure, and grant only the current session permission to access the local temporary table.

[0077] Specifically, the technical approach in this step is to quickly identify local temporary tables and ensure session access isolation by establishing an index mechanism. Unique identifiers are used to uniquely identify tables in the database and indicate the table that triggered the invalidation message in the invalidation message. The index data structure is used to store the unique identifiers corresponding to all local temporary tables.

[0078] In specific implementations, the unique identifier of each local temporary table consists of the session ID and sequence number of the current session. For example, this can be concatenated into a 64-bit integer as a composite key, with the session ID occupying 32 bits and the sequence number occupying 32 bits. The corresponding index data structure can be implemented using a Lock-Free Adaptive Radix Tree (LF-ART), for example. LF-ART has the following technical advantages:

[0079] 1. LF-ART is a tree data structure. In LF-ART, integer identifiers are compactly stored in a radix tree, allowing fast insertion and lookup operations.

[0080] Second, LF-ART can dynamically merge and split nodes to adapt to different key distributions. This allows the tree structure to automatically adjust according to the sparseness or density of the data, thereby optimizing storage and access efficiency;

[0081] 3. LF-ART uses CAS (Compare-and-Swap) atomic operations to update node pointers. This lock-free design can avoid the use of global locks, reduce lock contention, and improve concurrency performance.

[0082] The unique identifier is stored in the index data structure stage. Starting from the root node of LF-ART, each byte of the key can be matched layer by layer (for example, grouped by 8 bits), and the child node of the current node is checked to see if it contains a pointer corresponding to the next byte. If so, continue down along the path. If the child node capacity of the current node is insufficient (for example, Node4 is full), the node needs to be atomically upgraded to a larger node type (such as Node16 or Node48). CAS atomic operations are used when inserting new child node pointers. When reaching a leaf node, a metadata pointer related to the local temporary table is stored. The metadata pointer can include, for example, the table's OID, ACL (access control list) permissions, etc. The entire insertion process is completed by mounting the metadata to the leaf node.

[0083] Optionally, the index data structure can use a hash table (for example, with the table OID (object identifier) as the key and the session ID as the value). It should be noted that an OID is a unique identifier assigned to each object by some database systems. It is typically an unsigned integer and is used to uniquely identify each object within the database. When an invalidation message is triggered, the OID of the table that triggered the invalidation message is included in the invalidation message to indicate which table has changed. When creating a temporary table, the HASH_ENTER function is called to insert the key-value pair. Simultaneously, the table-level access control list (ACL) is modified to grant permissions only to the current session (for example, executing GRANT ALL ON temp_table TO CURRENT_SESSION). The primary advantage of a hash table is its direct addressing feature based on the hash function. This allows key-value pair queries and insertions to be completed in near-constant time, significantly improving the real-time performance of processing high-frequency invalidation messages. Furthermore, by using shard locks or lock-free designs, hash tables can optimize concurrent access, reduce resource contention in multi-threaded environments, and ensure stable performance in high-throughput scenarios. Their dynamically scalable memory management mechanism allows storage space to be flexibly adjusted based on data size, balancing memory efficiency and flexibility. Furthermore, hash tables have a simple and straightforward implementation structure, requiring no complex state maintenance or tree balancing operations. This makes them ideal for cross-platform deployment and heterogeneous system integration. By properly designing hash functions and conflict handling strategies, the probability of key conflicts can be minimized. This design ensures query efficiency and data consistency while offering a high cost-effectiveness for managing large-scale temporary tables.

[0084] In summary, the technical effect of this step is that the index data structure can be used to quickly determine whether it is a local temporary table, and combined with permission isolation, it can prevent other sessions from accessing it by mistake, thereby ensuring data security while improving the efficiency of invalidation message processing.

[0085] S202: When an invalidation message is triggered by operating a data table or an object on a data table in the current session, it is determined whether the data table that triggered the invalidation message is a local temporary table created in the current session:

[0086] Optionally, in this step, determining whether the data table that triggers the invalidation message is a local temporary table created in the current session includes:

[0087] Get the unique identifier in the invalidation message;

[0088] Check whether the unique identifier in the invalidation message is stored in the index data structure;

[0089] If found, confirm that the data table that triggered the invalidation message is a local temporary table;

[0090] If not found, confirm that the data table that triggers the invalidation message is not a local temporary table.

[0091] During the query process, if the unique identifier is a composite key consisting of the current session's session ID and sequence number, and the index data structure is LF-ART, the session ID and table name can be reverse-looked up based on the OID of the data table that triggered the invalidation message to generate a composite key. The LF-ART can then be traversed byte by byte, matching key values layer by layer from the root node to the leaf node. The session ID in the metadata is then verified to determine whether it is a local temporary table. If not, it is determined to be a regular table. LF-ART's lock-free design and adaptive node optimization enable efficient storage and high-speed query of unique identifiers for local temporary tables, improving invalidation message processing performance in high-concurrency scenarios.

[0092] If the unique identifier is the OID of the data table, then the unique identifier in the invalidation message is searched whether it is stored in the index data structure, including: searching whether the object identifier in the invalidation message is stored in the index data structure. Specifically, when the index data structure is a hash table, a HASH_FIND query can be performed based on the hash table (for example, the table OID is passed in to return whether the key exists) to determine whether the data table is a local temporary table.

[0093] If the data table that triggers the invalidation message is a local temporary table, then S203, store the invalidation message as the first message in the first storage data structure;

[0094] Specifically, the first storage data structure can be a first linked list. Due to the dynamic expansion characteristics and efficient insertion of the linked list, a one-way linked list (for example, maintaining the message linked list with the head insertion method and allocating node memory through palloc) or a two-way linked list can be used in the specific implementation. For example, in the one-way linked list solution, each node stores the invalid message type (such as DROP / ALTER), table OID and pointer. The insertion operation only needs to modify the head pointer and the next pointer of the new node, and the time complexity is relatively low. In terms of technical effect, the linked list uses lock-free insertion and dynamic memory allocation, so that the storage of the first message does not require pre-allocation of fixed memory, thereby reducing memory fragmentation and improving throughput in high-concurrency scenarios.

[0095] Optionally, the first storage data structure may be a first circular queue.

[0096] If the data table that triggers the invalidation message is not a local temporary table, then S204, store the invalidation message as a second message in a second storage data structure;

[0097] Specifically, the second storage data structure can be a second linked list. The second linked list can be a one-way linked list with a counter (for example, maintaining a linked list length counter to quickly count the number of messages) or a sharded linked list (for example, distributing the table OID hash value across multiple sub-linked lists to reduce lock contention). For example, when implementing a one-way linked list with a counter as the second linked list, the second linked list can be directly traversed and copied in batches to the shared invalidation message queue during transaction submission. Combined with the counter, the target memory space can be pre-allocated in advance. The sequential write feature of the linked list allows the storage and submission of non-temporary table invalidation messages to be separated, thereby reducing the frequency of lock contention in the shared invalidation message queue and improving the efficiency of global message broadcasting.

[0098] Optionally, the second storage data structure may also be a second circular queue.

[0099] S205: Apply the first message stored in the first storage data structure to the cache of the current session, and store the second message stored in the second storage data structure to a shared invalidation message queue, which is used to broadcast the second message to all sessions.

[0100] When both the first storage data structure and the second storage data structure are linked lists, in specific implementation, for example, the first linked list (first message) can be traversed and the InvalidateLocalCache function can be called one by one (for example, to clear the query plan cache). For the second linked list (second message), the linked list head pointer can be mounted to the tail of the shared invalidation message queue through atomic operations, and the background process can asynchronously traverse the linked list and broadcast messages.

[0101] Figure 3 This is a schematic diagram of the structure of the database failure message mechanism optimization device provided by this application, such as Figure 3 As shown, the database invalidation message mechanism optimization device 30 provided in this embodiment includes:

[0102] The data table type determination module 301 is used to determine whether the data table that triggered the invalidation message is a local temporary table created in the current session when the current session operates a data table or an object on the data table.

[0103] If the data table that triggers the invalidation message is a local temporary table, the invalidation message is stored as the first message in the first storage data structure;

[0104] If the data table that triggers the invalidation message is not a local temporary table, the invalidation message is stored as a second message in the second storage data structure;

[0105] Invalidation message application module 302 is configured to apply the first message stored in the first storage data structure to the cache of the current session and to store the second message stored in the second storage data structure in a shared invalidation message queue. The shared invalidation message queue is used to broadcast the second message to all sessions. The database invalidation message mechanism optimization device provided in this embodiment can implement the method provided in the above-mentioned method embodiment. Its implementation principles and technical effects are similar and are not further described in this embodiment.

[0106] Figure 4 This is a schematic diagram of the structure of the electronic device provided in this application. Figure 4 As shown, the electronic device 40 provided in this embodiment includes: at least one processor 401 and a memory 402. Optionally, the device 40 further includes a communication component 403. The processor 401, the memory 402 and the communication component 403 are connected via a bus 404.

[0107] In a specific implementation process, at least one processor 401 executes the computer-executable instructions stored in the memory 402, so that the at least one processor 401 performs the above method.

[0108] The specific implementation process of the processor 401 can be found in the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here in this embodiment.

[0109] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASICs), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the present invention may be directly executed by a hardware processor or by a combination of hardware and software modules within the processor.

[0110] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage.

[0111] A bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Buses can be categorized as address buses, data buses, and control buses. For ease of illustration, the buses in the drawings of this application are not limited to just one bus or just one type of bus.

[0112] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0113] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

[0114] The readable storage medium may be implemented by any type of volatile or non-volatile memory device, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium may be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0115] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be an integral part of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0116] The division of units is merely a logical functional division; actual implementations may employ alternative divisions, such as combining or integrating multiple units or components into another system, or omitting or disabling certain features. Furthermore, any direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units, either through an interface, electrical, mechanical, or other means.

[0117] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0118] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0119] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the portion that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the method of the present invention. The aforementioned storage medium includes various media that can store program code, such as USB flash drives, mobile hard drives, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical disks.

[0120] Those skilled in the art will appreciate that all or part of the steps in the above-described method embodiments can be implemented using hardware associated with program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0121] Finally, it should be noted that those skilled in the art will readily identify other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses, or adaptations of the present invention that follow the general principles of the present invention and include common knowledge or customary techniques in the art not disclosed herein. The present invention is not limited to the precise structure described above and illustrated in the accompanying drawings, and various modifications and variations may be made without departing from the scope thereof. The scope of the present invention is limited solely by the appended claims.

Claims

1. A method for optimizing a database invalidation message mechanism, characterized in that: The method comprises: When an invalidation message is triggered by operating a data table or an object on a data table in the current session, it is determined whether the data table that triggered the invalidation message is a local temporary table created by the current session: If the data table that triggers the invalidation message is the local temporary table, storing the invalidation message as the first message in the first storage data structure; If the data table that triggers the invalidation message is not the local temporary table, storing the invalidation message as a second message in a second storage data structure; The first message stored in the first storage data structure is applied to the cache of the current session, and the second message stored in the second storage data structure is stored in a shared invalidation message queue, which is used to broadcast the second message to all sessions.

2. The method according to claim 1, characterized in that The determining whether the data table that triggers the invalidation message is a local temporary table created for the current session includes: Obtaining a unique identifier in the invalidation message, where the unique identifier is used to uniquely identify a data table in a database, and indicating in the invalidation message the data table that triggers the invalidation message; Searching whether the unique identifier in the invalidation message is stored in an index data structure, the index data structure being used to store the unique identifiers corresponding to all the local temporary tables; If found, confirm that the data table that triggers the invalidation message is the local temporary table; If not found, it is confirmed that the data table that triggers the invalidation message is not the local temporary table.

3. The method according to claim 2, characterized in that The obtaining of the unique identifier in the invalidation message includes: obtaining an object identifier in the invalidation message as the unique identifier, wherein the object identifier is assigned to each data table by a database and is used to uniquely identify the data table in the database, and indicating the data table that triggers the invalidation message in the invalidation message; The searching whether the unique identifier in the invalidation message is stored in the index data structure includes: A search is performed to determine whether the object identifier in the invalidation message is stored in the index data structure.

4. The method according to claim 2 or 3, characterized in that The searching whether the unique identifier in the invalidation message is stored in the index data structure includes: A hash table is searched to determine whether the unique identifier in the invalidation message is stored. The hash table serves as the index data structure and is used to store the unique identifiers corresponding to all the local temporary tables.

5. The method according to claim 1, characterized in that If the data table that triggers the invalidation message is the local temporary table, storing the invalidation message as the first message in the first storage data structure includes: Storing the first message in a first linked list serving as the first storage data structure; If the data table that triggers the invalidation message is not the local temporary table, storing the invalidation message as a second message in a second storage data structure includes: The second message is stored in a second linked list serving as the second storage data structure.

6. The method according to claim 1, characterized in that If the data table that triggers the invalidation message is the local temporary table, storing the invalidation message as the first message in the first storage data structure includes: storing the first message in a first circular queue serving as the first storage data structure; If the data table that triggers the invalidation message is not the local temporary table, storing the invalidation message as a second message in a second storage data structure includes: The second message is stored in a second circular queue as the second storage data structure.

7. The method according to claim 2, characterized in that When the current session operates a data table or an object on the data table and triggers an invalidation message, before determining whether the data table that triggers the invalidation message is a local temporary table created by the current session, the method further includes: The index data structure is created, and whenever the current session creates the local temporary table, the unique identifier corresponding to the currently created local temporary table is stored in the index data structure, and only the current session is granted permission to access the local temporary table.

8. A database invalidation message mechanism optimization device, characterized in that: The device comprises: The data table type determination module is used to: when an invalidation message is triggered by operating a data table or an object on a data table in the current session, determine whether the data table that triggered the invalidation message is a local temporary table created in the current session: If the data table that triggers the invalidation message is the local temporary table, storing the invalidation message as the first message in the first storage data structure; If the data table that triggers the invalidation message is not the local temporary table, storing the invalidation message as a second message in a second storage data structure; An invalidation message application module is used to apply the first message stored in the first storage data structure to the cache of the current session, and store the second message stored in the second storage data structure to a shared invalidation message queue, and the shared invalidation message queue is used to broadcast the second message to all sessions.

9. An electronic device, characterized in that: include: a processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the database invalidation message mechanism optimization method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the database invalidation message mechanism optimization method according to any one of claims 1 to 7.

Images