Reuse method, device and equipment of table intention lock and medium
By caching and reusing table intent locks in the database session, the problem of degraded concurrency performance caused by table lock contention in the database system is solved, and data processing efficiency is improved.
Patent Information
- Application Number
- CN202511133924.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-14
- Publication Date
- 2025-11-14
AI Technical Summary
In database systems, when a large number of transactions simultaneously request table locks for the same table, it leads to high-frequency contention for the global mutex table_lock.m_mutex, resulting in decreased concurrency performance and reduced data processing efficiency.
By caching table intention locks in the session and reusing the cached table intention locks when conditions are met, duplicate acquisition of table_lock.m_mutex is avoided.
It reduces critical section conflicts during the process of acquiring table locks for the same table, improves concurrent processing performance, shortens transaction waiting time, and enhances database data processing efficiency.
Smart Images
Figure CN120950059A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of database technology, and in particular to a method, apparatus, device and medium for reusing expression intention locks. Background Technology
[0002] In database systems, locking mechanisms are a key technology for ensuring the consistency and integrity of data within tables. Table locks are one of the common lock granularities in database systems, including types such as table intention locks, table exclusive locks, and table shared locks.
[0003] In real-world production environments, transactions primarily involve data creation, deletion, modification, and querying (DML operations). To prevent table structure modifications during these operations (DDL operations), the database applies appropriate table locks and implements concurrency control through lock compatibility mechanisms. From an implementation perspective, when applying or releasing a table lock, the database first needs to acquire the table's global mutex, `table_lock.m_mutex`, to safely access and modify the lock's state information (`table_lock.lock_info`).
[0004] However, when a large number of DML operations simultaneously request table locks for the same table (or a few tables), it leads to high-frequency contention for table_lock.m_mutex, resulting in decreased concurrency performance and ultimately reducing the database's data processing efficiency. Summary of the Invention
[0005] To address the aforementioned issues, this application provides a method, apparatus, device, and medium for reusing table intention locks, which can reduce critical section conflicts during the process of acquiring table locks for the same table and improve concurrent processing performance.
[0006] The embodiments of this application disclose the following technical solutions: Firstly, this application discloses a method for reusing intention locks, the method comprising: When the first transaction is committed in the session, if the first transaction holds a table intention lock on the target table and there are no other transactions waiting for a table exclusive lock or table intention lock on the target table, then the table intention lock on the target table is cached in the session. When a second transaction is submitted in the session, if the second transaction indicates the target table, and the session has cached the table intention lock of the target table, and the table lock of the target table indicated by the second transaction is a table intention lock, then the cached table intention lock of the target table is reused.
[0007] Optionally, if the first transaction holds a table intention lock on the target table, and no other transaction is waiting for a table exclusive lock or table intention lock on the target table, then caching the table intention lock on the target table in the session includes: If the first transaction holds a table intention lock on the target table, and determines, based on the bwait variable in the table lock information structure, that no other transaction is waiting for the table exclusive lock or table intention lock on the target table, then the table intention lock on the target table is cached in the session.
[0008] Optionally, the method further includes: When the first transaction is committed in the session, if the first transaction holds a non-table intention lock on the target table, or if there are other transactions waiting for a table exclusive lock or table intention lock on the target table, the table lock is released after the first transaction is completed. The non-table intention lock includes table exclusive locks and table shared locks.
[0009] Optionally, the method further includes: After the first transaction is committed in the session, if no other transactions are received from the session within the timeout period, the table intention lock of the target table cached in the session is released.
[0010] Optionally, the method further includes: If no other statements of the first transaction are received within the timeout period after the first statement of the first transaction is submitted in the session, the table intention lock of the target table cached in the session is released.
[0011] Optionally, the method further includes: If it is detected that the first transaction holds a table lock on the first target table and is waiting for a table lock on the second target table, and the second transaction holds a table lock on the second target table and is waiting for a table lock on the first target table, then release the table locks on the first target table or the second target table.
[0012] Secondly, this application discloses a table lock multiplexing device, the device comprising: a table lock caching module and a table lock multiplexing module; The table lock caching module is used to cache the table intention lock of the target table in the session when the first transaction is committed in the session, if the first transaction holds a table intention lock of the target table and there are no other transactions waiting for the table exclusive lock or table intention lock of the target table. The table lock reuse module is configured to reuse the cached table intention lock of the target table when a second transaction is submitted in the session, provided that the second transaction indicates the target table, the session has cached the table intention lock of the target table, and the table lock of the target table indicated by the second transaction is a table intention lock.
[0013] Optionally, the table lock caching module is specifically used to: if the first transaction holds a table intention lock on the target table, and determines, based on the bwait variable in the table lock information structure, that there are no other transactions waiting for the table exclusive lock or table intention lock on the target table, then cache the table intention lock on the target table in the session.
[0014] Optionally, the device further includes: a watch lock release module; The table lock release module is used to release the table lock after the first transaction is completed when the first transaction is committed in the session, if the first transaction holds a non-table intention lock on the target table, or if there are other transactions waiting for the table exclusive lock or table intention lock on the target table. The non-table intention lock includes table exclusive lock and table shared lock.
[0015] Optionally, the table lock release module is further configured to: after committing the first transaction in the session, if no other transaction is received from the session within the timeout period, release the table intention lock of the target table cached in the session.
[0016] Optionally, the table lock release module is further configured to: after the first statement of the first transaction is submitted in the session, if no other statements of the first transaction are received within the timeout period, release the table intention lock of the target table cached in the session.
[0017] Optionally, the table lock release module is further configured to release the table lock of the first target table or the second target table if it is detected that the first transaction holds a table lock of the first target table and is waiting for a table lock of the second target table, and the second transaction holds a table lock of the second target table and is waiting for a table lock of the first target table.
[0018] Thirdly, this application discloses a multiplexing device for an intention lock, the device comprising: a memory and a processor; The memory is used to store programs; The processor is configured to execute the program to implement the steps of the intention lock reuse method as described in the first aspect.
[0019] Fourthly, this application discloses a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the intention lock reuse method as described in the first aspect.
[0020] Compared with the prior art, this application has the following beneficial effects: This application provides a method, apparatus, device, and medium for reusing table intention locks. The method includes: when a first transaction is committed in a session, if the first transaction holds a table intention lock on a target table and no other transactions are waiting for an exclusive table lock or table intention lock on the target table, then the table intention lock on the target table is cached in the session; when a second transaction is committed in the session, if the second transaction indicates a target table, and the table intention lock on the target table is cached in the session, and the table lock on the target table indicated by the second transaction is a table intention lock, then the cached table intention lock on the target table is reused. Therefore, by caching the table intention lock on the target table in the session, when other transactions in the same session indicating the same target table require table locks of the same level, the cached table intention lock on the target table can be directly reused, avoiding repeated acquisition of `table_lock.m_mutex`, thereby reducing critical section conflicts during the acquisition of table locks for the same table and improving concurrent processing performance. Attached Figure Description
[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0022] Figure 1 A flowchart illustrating a method for reusing an intention lock as provided in an embodiment of this application; Figure 2 A flowchart illustrating another method for reusing an intention lock as provided in an embodiment of this application; Figure 3 A schematic diagram of a multiplexing device for an intention lock provided in an embodiment of this application; Figure 4 This is a schematic diagram of a computer-readable medium provided in an embodiment of this application. Detailed Implementation
[0023] As described earlier, table locks are one of the common lock granularities in database systems. Table locks include types such as table intention locks (LOCK_IS, LOCK_IX), table exclusive locks (LOCK_X), and table shared locks (LOCK_S).
[0024] In real-world production environments, transactions primarily involve data creation, deletion, modification, and querying (DML operations). To prevent table structure modifications during these operations (DDL operations), the database applies appropriate table locks and implements concurrency control through lock compatibility mechanisms. From an implementation perspective, when applying or releasing a table lock, the database first needs to acquire the table's global mutex, `table_lock.m_mutex`, to safely access and modify the lock's state information (`table_lock.lock_info`).
[0025] However, when a large number of DML operations simultaneously request table locks for the same table (or a few tables), it leads to high-frequency contention for table_lock.m_mutex, resulting in decreased concurrency performance and ultimately reducing the database's data processing efficiency.
[0026] Through research, the inventors have proposed a method, apparatus, device, and medium for reusing table intention locks. The method includes: when a first transaction is committed in a session, if the first transaction holds a table intention lock on the target table, and no other transactions are waiting for an exclusive table lock or table intention lock on the target table, then the table intention lock on the target table is cached in the session; when a second transaction is committed in the session, if the second transaction indicates a target table, and the table intention lock on the target table is cached in the session, and the table lock on the target table indicated by the second transaction is a table intention lock, then the cached table intention lock on the target table is reused. Therefore, by caching the table intention lock on the target table in the session, when other transactions in the same session indicating the same target table require table locks of the same level, the cached table intention lock on the target table can be directly reused, avoiding repeated acquisition of `table_lock.m_mutex`, thereby reducing critical section conflicts during the acquisition of table locks for the same table and improving concurrent processing performance.
[0027] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.
[0028] See Figure 1 The figure is a flowchart of a method for reusing an intention lock according to an embodiment of this application. The method includes: S101: When the first transaction is committed in the session, if the first transaction holds a table intention lock on the target table and there are no other transactions waiting for an exclusive table lock or table intention lock on the target table, then the table intention lock on the target table is cached in the session.
[0029] A table intention lock is a table-level logical lock in a database used to identify a transaction's potential intention to manipulate data in a target table. Table intention locks include intention shared locks and intention exclusive locks. An intention shared lock (LOCK_IS) indicates the possibility of acquiring a row-shared lock on certain records in the target table in the future, while an intention exclusive lock (LOCK_IX) indicates the possibility of acquiring a row-exclusive lock on certain records in the target table in the future. Furthermore, intention shared locks and intention exclusive locks do not conflict with each other.
[0030] A table exclusive lock (LOCK_X) is a logical lock that allows a transaction to exclusively access a target table after acquiring a write lock, preventing other transactions from reading or writing to the table during this period, thus ensuring the atomicity and isolation of data modifications.
[0031] A session is a connection established between a client application and a database server, used to execute transactions or SQL statements.
[0032] When a client application commits its first transaction in a session, if the first transaction holds a table intention lock on the target table and no other transactions are waiting to acquire an exclusive table lock or table intention lock on the target table, the database server will cache the table intention lock on the target table in the session.
[0033] Therefore, by caching table intent locks to the session, subsequent transactions within the same session that need to add the same level of table intent lock to the same target table can directly reuse the cached lock in the session without having to repeatedly request lock resources from the database.
[0034] S102: When a second transaction is committed in a session, if the second transaction indicates the target table, and the session has cached the table intention lock of the target table, and the table lock of the target table indicated by the second transaction is a table intention lock, then the cached table intention lock of the target table is reused.
[0035] When a second transaction is committed within the same session, the cached table intent lock for the target table can be reused directly if the following three conditions are met: First, the target table indicated by the second transaction is the same as the target table corresponding to the table intention lock cached in step S101. This means that if the first transaction caches a table intention lock on table T1, then this table intention lock can only be reused if the second transaction also needs to operate on table T1.
[0036] Second, the intention lock of the target table has been cached in the session. This means that a previous transaction (the first transaction in this embodiment) has successfully acquired the intention lock of the target table, and based on the situation at that time, it was determined that it could be cached for later use.
[0037] Third, the table lock on the target table indicated by the second transaction is a table intention lock. This means that the table lock on the target table indicated by the second transaction has the same level as the table intention lock on the cached target table. Conversely, if the first transaction caches a table intention lock, but the second transaction needs a table exclusive lock or a table shared lock, then the cached table intention lock cannot be reused directly.
[0038] When all three conditions above are met, the database server will reuse the table intention lock of the target table already cached in the session, without needing to request lock resources again. Therefore, this reuse mechanism can significantly reduce the probability of thread blocking caused by lock contention in high-concurrency scenarios, shorten transaction waiting time, and improve the database's data processing efficiency.
[0039] In summary, this application discloses a method for reusing table intention locks. The method includes: when a first transaction is committed in a session, if the first transaction holds a table intention lock on the target table, and no other transactions are waiting for an exclusive table lock or table intention lock on the target table, then the table intention lock on the target table is cached in the session; when a second transaction is committed in the session, if the second transaction indicates a target table, and the table intention lock on the target table is cached in the session, and the table lock on the target table indicated by the second transaction is a table intention lock, then the cached table intention lock on the target table is reused. Therefore, by caching the table intention lock on the target table in the session, when other transactions in the same session indicating the same target table require table locks of the same level, the cached table intention lock on the target table can be directly reused, avoiding repeated acquisition of `table_lock.m_mutex`, thereby reducing critical section conflicts during the acquisition of table locks for the same table and improving concurrent processing performance.
[0040] See Figure 2 The figure is a flowchart of another intention lock reuse method provided in an embodiment of this application. The method includes: S201: When the first transaction is committed in the session, if the first transaction holds a table intention lock on the target table, determine whether there are other transactions waiting for an exclusive table lock or a table intention lock on the target table. If yes, execute S202; otherwise, execute S203.
[0041] When the client application commits the first transaction in the session, if the first transaction holds a table intention lock (LOCK_IS or LOCK_IX) on the target table, the following judgment is performed: The atomic boolean variable `atomic_boolbwait` in the `table_lock.lock_info` structure determines whether other transactions are waiting for an exclusive lock or intention lock on the target table. The `atomic_boolbwait` variable is of type `atomic_bool`, used to ensure the atomicity of read and write operations in a multi-threaded environment, avoiding locking access under multi-threaded conditions and improving access efficiency.
[0042] In one example, when the first transaction is committed in the session, if the first transaction holds a table intention lock on the target table, and the DDL operation requires acquiring an exclusive table lock on the target table, then the DDL operation will be placed in the waiting queue, and table_lock.lock_info.bwait will be set to true. At this point, step S202 is executed.
[0043] In another example, when the first transaction is committed in the session, if the first transaction holds a table intention lock on the target table, and CRUD operations require acquiring the table intention lock on the target table, then the CRUD operations do not need to be placed in the waiting queue, and table_lock.lock_info.bwait remains false. At this point, step S202 is executed.
[0044] When the first transaction is committed in the session, if the first transaction holds a table intention lock on the target table, and it is determined from the bwait variable in the table lock information structure that there are no other transactions waiting for an exclusive table lock or table intention lock on the target table, then step S203 is executed.
[0045] S202: Release the table lock after the first transaction is completed.
[0046] When the first transaction is committed in a session, if the first transaction holds a non-table intention lock (including exclusive and shared locks) on the target table, or if other transactions are waiting for an exclusive or intention lock on the target table, the table locks are released after the first transaction completes. This releases unnecessary lock resources as quickly as possible after the first transaction finishes, allowing other transactions to use them. This not only simplifies the complexity of lock management but also enhances the stability and maintainability of the database server.
[0047] S203: Cache the target table's table intention lock in the session. Then, execute S204.
[0048] If no other transaction is waiting for the table exclusive lock or table intention lock of the target table, the table intention lock is not released. Instead, the table intention lock of the target table is cached in the session for the next transaction on the connection to continue using.
[0049] Therefore, caching the target table's intention lock in the session aims to allow other transactions within the same session to reuse the cached intention lock without accessing the table's global lock information (table_lock.lock_info). This not only reduces the frequency of thread switching, thereby reducing system overhead, but also shortens transaction waiting time and improves database data processing efficiency.
[0050] S204: When a second transaction is committed in the session, determine whether the following conditions are met: the second transaction indicates the target table, the session has cached the table intention lock of the target table, and the table lock of the target table indicated by the second transaction is a table intention lock. If so, proceed to step S205.
[0051] When a second transaction is committed within the same session, the following actions are performed: First, determine if the second transaction indicates the same target table as the first transaction (ensuring that only operations on the same table can reuse cached table intention locks). If the second transaction indicates the same target table as the first transaction, then proceed to determine if the table intention lock for the target table is already cached in the session.
[0052] If the target table's intention lock is already cached in the session, then it continues to determine whether the target table lock indicated by the second transaction is also a intention lock, that is, whether the target table lock indicated by the second transaction has the same level as the cached target table's intention lock. If the target table's intention lock is not cached in the session, then the required lock is obtained according to the target table's table lock information structure table_lock.lock_info.
[0053] If the table lock on the target table indicated by the second transaction is a table intention lock, then step S205 is executed. If the table lock on the target table indicated by the second transaction is not a table intention lock, but a table exclusive lock or a table shared lock, then the cached table intention lock on the target table can be upgraded, or the table lock can be reacquired after releasing the cached table intention lock on the target table.
[0054] Taking the second transaction performing DDL (Data Definition Language) operations on table t1, and the session caching the table intention lock for table t1 as an example: The DDL operation requires acquiring an exclusive table lock. Therefore, the table lock (i.e., the exclusive lock) of the target table indicated by the second transaction is inconsistent with the level of the cached table intention lock. First, the cached table intention lock for the target table is released. Then, an attempt is made to acquire the exclusive table lock for table t1. If the acquisition is successful, the DDL operation is executed. If the acquisition fails, for example, if the exclusive table lock for table t1 is already held by another transaction, the `table_lock.lock_info.bWait` variable is set to true, and the transaction enters the lock queue to wait.
[0055] If other sessions also cache table intention locks for table t1, these locks will be released after a new transaction is committed within that session. At this point, if a DDL operation is still waiting for a lock, it has a chance to acquire an exclusive lock on table t1. If no new transactions are committed in other sessions, or if a transaction is in progress without a subsequent statement arriving, the session connection between the client application and the database server is forcibly terminated based on the timeout duration `kill_idle_connect_timeout`. After the session connection is closed, the database server releases all cached table intention locks in the session. In other words, after a maximum of `kill_idle_connect_timeout`, the DDL operation can acquire an exclusive lock on table t1, because by then all table intention locks that might have affected the DDL operation's acquisition of an exclusive lock have been released.
[0056] S205: Table intention lock for the target table of the cache reused table.
[0057] When a second transaction is committed within a session, if the target table indicated by the second transaction is satisfied, and the session has already cached the table intention lock for the target table, and the table lock indicated by the second transaction for the target table is also a table intention lock, then the cached table intention lock for the target table is reused. This means that the second transaction can directly use the previously cached table intention lock for the target table without requesting a new lock resource again. This approach significantly reduces the workload of the lock manager because it avoids repeated lock requests and releases. Furthermore, because it reduces lock contention during table lock acquisition (e.g., changing from the previous locked access via `table_lock.m_mutex` to the optimized lock-free access via `table_lock.lock_info.bwait`), the overall system performance is also improved, as this reduces thread switching frequency and waiting time caused by lock contention.
[0058] It's important to note that in database operations, client applications establish connections with the database server through sessions. When a session ends, the database server needs to ensure that all session-related resources (such as locks) are correctly released. This is because if locks are not released after the session ends, these locks will continue to occupy the database server's resources, preventing other transactions from acquiring locks and thus blocking operations. Furthermore, cached locks may create a circular wait with lock requests from other transactions, leading to deadlocks. Therefore, lock release is a crucial guarantee for transaction isolation and consistency. After the connection is broken, related transactions may not be completed. In this case, incomplete transactions will be rolled back; if a transaction completes normally, it will be committed. Regardless of whether a transaction is committed or rolled back, lock resources will be released.
[0059] It should also be noted that the database server can support deadlock detection. Deadlock refers to a situation where multiple transactions are unable to continue execution because they are waiting for locks held by each other. In one specific implementation, taking two transactions as an example, if it is detected that the first transaction holds a table lock on the first target table and is waiting for a table lock on the second target table, and the second transaction holds a table lock on the second target table and is waiting for a table lock on the first target table, then a deadlock is determined. The database server can then select one of the transactions to disconnect and release the table locks on either the first or second target table, based on factors such as the transaction's waiting time, transaction priority, and the operations already performed. For example, the database server can choose to disconnect the first transaction with the longer waiting time, or the first transaction with a lower priority, or the first transaction with fewer operations performed. Therefore, the table intention lock reuse method provided in this application can quickly break the deadlock cycle, allowing other transactions to continue execution, thereby releasing occupied transaction resources (such as memory, locks, etc.) and improving system resource utilization.
[0060] It should also be noted that the database system can configure the `kill_idle_connect_timeout` parameter, which specifies the timeout duration (usually set to minutes to hours, depending on the application scenario). In one specific implementation, after the first transaction is committed in the session, if no other transactions from the same session are received within the timeout period (i.e., the previous transaction on the connection has ended and no new transactions have started since), or if no other statements from the first transaction are received within the timeout period (i.e., a new transaction was connected, but after executing some statements, no new statements were executed for a long time), then the session connection between the client application and the database server is disconnected.
[0061] Understandably, the main reasons for configuring timeout durations include the following three points: First, to avoid impacting the overall system's operational logic after a connection caches table intention locks. Specifically, to prevent other connections from caching table locks and then being unable to acquire exclusive table locks when no new transactions occur. Second, connections consume database server resources (such as memory, threads, and locks). Connections idle for extended periods waste resources and impact system performance. Setting a timeout ensures these resources are reclaimed and reallocated to other needed connections at appropriate times, improving resource utilization. Third, client applications may forget to close connections due to program errors or network problems, leading to connection leaks. By implementing a timeout disconnection mechanism, the database server can automatically close connections after detecting prolonged inactivity, effectively cleaning up leaked connections, reducing the risk of attacks, and maintaining healthy system operation.
[0062] It should also be noted that the method for reusing expression locks disclosed in the embodiments of this application is applicable to both single-machine databases and distributed databases; it is applicable to both single-connection, single-threaded database models and thread pool models.
[0063] In summary, this application discloses a method for reusing table intention locks. The method includes: when a first transaction is committed in a session, if the first transaction holds a table intention lock on the target table, and no other transactions are waiting for an exclusive table lock or table intention lock on the target table, then the table intention lock on the target table is cached in the session; when a second transaction is committed in the session, if the second transaction indicates a target table, and the table intention lock on the target table is cached in the session, and the table lock on the target table indicated by the second transaction is a table intention lock, then the cached table intention lock on the target table is reused. Therefore, by caching the table intention lock on the target table in the session, when other transactions in the same session indicating the same target table require table locks of the same level, the cached table intention lock on the target table can be directly reused, avoiding repeated acquisition of `table_lock.m_mutex`, thereby reducing critical section conflicts during the acquisition of table locks for the same table and improving concurrent processing performance.
[0064] See Figure 3 This figure is a schematic diagram of a table intention lock multiplexing device provided in an embodiment of this application. The table intention lock multiplexing device 300 includes: a table lock cache module 301 and a table lock multiplexing module 302; The table lock caching module 301 is used to cache the table intention lock of the target table in the session when the first transaction is committed in the session, if the first transaction holds a table intention lock of the target table and there are no other transactions waiting for the table exclusive lock or table intention lock of the target table. The table lock reuse module 302 is used to reuse the cached table intention lock of the target table when a second transaction is committed in a session, if the second transaction indicates the target table, and the table intention lock of the target table has been cached in the session, and the table lock of the target table indicated by the second transaction is a table intention lock.
[0065] In one specific implementation, the table lock caching module 301 is specifically used to: if the first transaction holds a table intention lock on the target table, and determines, based on the bwait variable in the table lock information structure, that there are no other transactions waiting for the exclusive table lock or table intention lock on the target table, then cache the table intention lock on the target table in the session.
[0066] In one specific implementation, the multiplexing device 300 for the expression intention lock further includes: a lock release module; The table lock release module is used to release table locks after the first transaction is completed when the first transaction is committed in the session. If the first transaction holds a non-table intention lock on the target table, or if there are other transactions waiting for a table intention lock on the target table, the non-table intention lock includes exclusive table locks or shared table locks.
[0067] In one specific implementation, the table lock release module is also used to: after the first transaction is committed in the session, if no other transaction is received from the session within the timeout period, release the table intention lock of the target table cached in the session.
[0068] In one specific implementation, the table lock release module is also used to: after the first statement of the first transaction is committed in the session, if no other statements of the first transaction are received within the timeout period, release the table intention lock of the target table cached in the session.
[0069] In one specific implementation, the table lock release module is further configured to release the table locks of the first target table and the second target table if it is detected that the first transaction holds a table lock on the first target table and is waiting for a table lock on the second target table, and the second transaction holds a table lock on the second target table and is waiting for a table lock on the first target table.
[0070] In summary, this application discloses a table intention lock reuse device. By caching the table intention lock of the target table in the session, when other transactions in the same session that indicate the same target table need the same level of table lock, the cached table intention lock of the target table can be directly reused, avoiding repeated acquisition of table_lock.m_mutex, thereby reducing critical section conflicts in the process of acquiring the table lock of the same table and improving concurrent processing performance.
[0071] This application also provides a corresponding intention lock multiplexing device and a computer-readable medium for implementing the intention lock multiplexing method provided in this application.
[0072] The intention lock multiplexing device includes a memory and a processor. The memory is used to store instructions or code, and the processor is used to execute the instructions or code to cause the device to perform an intention lock multiplexing method according to any embodiment of this application.
[0073] See Figure 4 This figure is a schematic diagram of a computer-readable medium provided in an embodiment of this application. The computer-readable medium 400 stores a computer program 411, which, when executed by a processor, implements the above-described... Figure 1 The steps of the expression lock reuse method.
[0074] It should be noted that, in the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0075] It should be noted that the machine-readable medium described above in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.
[0076] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.
[0077] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.
[0078] While several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this application. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.
[0079] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.
Claims
1. A method for reusing intention locks, characterized in that, The method includes: When the first transaction is committed in the session, if the first transaction holds a table intention lock on the target table and there are no other transactions waiting for a table exclusive lock or table intention lock on the target table, then the table intention lock on the target table is cached in the session. When a second transaction is submitted in the session, if the second transaction indicates the target table, and the session has cached the table intention lock of the target table, and the table lock of the target table indicated by the second transaction is a table intention lock, then the cached table intention lock of the target table is reused.
2. The method according to claim 1, characterized in that, If the first transaction holds a table intention lock on the target table, and no other transaction is waiting for a table exclusive lock or table intention lock on the target table, then caching the table intention lock on the target table in the session includes: If the first transaction holds a table intention lock on the target table, and determines, based on the bwait variable in the table lock information structure, that no other transaction is waiting for the table exclusive lock or table intention lock on the target table, then the table intention lock on the target table is cached in the session.
3. The method according to claim 1 or 2, characterized in that, The method further includes: When the first transaction is committed in the session, if the first transaction holds a non-table intention lock on the target table, or if there are other transactions waiting for a table exclusive lock or table intention lock on the target table, the table lock is released after the first transaction is completed. The non-table intention lock includes table exclusive locks and table shared locks.
4. The method according to claim 1 or 2, characterized in that, The method further includes: After the first transaction is committed in the session, if no other transactions are received from the session within the timeout period, the table intention lock of the target table cached in the session is released.
5. The method according to claim 1 or 2, characterized in that, The method further includes: If no other statements of the first transaction are received within the timeout period after the first statement of the first transaction is submitted in the session, the table intention lock of the target table cached in the session is released.
6. The method according to claim 1 or 2, characterized in that, The method further includes: If it is detected that the first transaction holds a table lock on the first target table and is waiting for a table lock on the second target table, and the second transaction holds a table lock on the second target table and is waiting for a table lock on the first target table, then release the table locks on the first target table or the second target table.
7. A multiplexing device for an intention-expressing lock, characterized in that, The device includes: a table lock cache module and a table lock multiplexing module; The table lock caching module is used to cache the table intention lock of the target table in the session when the first transaction is committed in the session, if the first transaction holds a table intention lock of the target table and there are no other transactions waiting for the table exclusive lock or table intention lock of the target table. The table lock reuse module is configured to reuse the cached table intention lock of the target table when a second transaction is submitted in the session, provided that the second transaction indicates the target table, the session has cached the table intention lock of the target table, and the table lock of the target table indicated by the second transaction is a table intention lock.
8. The apparatus according to claim 7, characterized in that, The table lock caching module is specifically used to: if the first transaction holds a table intention lock on the target table, and determines, based on the bwait variable in the table lock information structure, that there are no other transactions waiting for the table exclusive lock or table intention lock on the target table, then cache the table intention lock on the target table in the session.
9. A multiplexing device for an intention-expressing lock, characterized in that, The device includes: a memory and a processor; The memory is used to store programs; The processor is configured to execute the program to implement the steps of the intention lock reuse method as described in any one of claims 1 to 6.
10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the intention lock reuse method as described in any one of claims 1 to 6.