Batch data write deadlock prevention method, device and equipment based on primary key ordering

Abstract

This application provides a method, apparatus, and device for preventing deadlocks in batch data writing based on primary key ordering. The method involves extracting the primary key and normalizing its type from the set of records to be written to generate a normalized primary key string; performing primary key ordering sorting based on the normalized primary key string to generate a logically ordered record sequence; performing intelligent batch sharding on the logically ordered record sequence to generate sharded record batches; and performing batch data writing based on the sharded record batches according to their ordered arrangement, while also implementing adaptive concurrency adjustment and backoff retries. This scheme, by forcing all concurrent transactions to acquire locks in a completely consistent order, mathematically breaks the circular wait condition that leads to deadlocks, reducing the deadlock rate to an extremely low level and improving data processing throughput and system stability in high-concurrency scenarios.

Description

Technical Field

[0001] This application relates to the field of database concurrency control and deadlock prevention technology, and more specifically, to a method, apparatus and device for preventing deadlock in batch data writing based on primary key ordering. Background Technology

[0002] As enterprise applications increasingly demand high-concurrency data processing capabilities, the stability of relational databases during batch update or insert (UPSERT) operations has become a core concern. Ensuring that the database maintains high throughput without deadlocking in high-frequency data synchronization and real-time business processing scenarios is a key technical challenge for guaranteeing continuous system operation.

[0003] Existing batch write technologies typically employ single-row sequential write mode, batch SQL concatenation mode, or pre-compiled batch execution mode. This approach first collects the data stream to be written generated by the business side; then, it sends the data packets directly to the execution engine through a database connection pool; finally, the database engine executes the write operation according to the default physical storage order or index layout.

[0004] However, this existing solution has significant technical flaws. Its core flaw lies in the lack of a systematic lock acquisition order control mechanism, leading to circular waiting deadlocks among concurrent transactions. When handling high-concurrency batch UPSERTs, the randomness of the processing order of different transactions on the same primary key set causes the acquisition order of row locks and gap locks to overlap, resulting in circular waiting. When transaction A holds the lock on record 1 and requests record 2, while transaction B holds the lock on record 2 and requests record 1, the system will trigger a deadlock and force a transaction rollback. This randomized lock contention can cause the deadlock rate to skyrocket in extremely high-concurrency environments, severely consuming computational and I / O resources and reducing the overall system throughput. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides a method, apparatus, and device for preventing deadlocks in batch data writing based on primary key ordering, thereby at least mitigating the aforementioned technical problems.

[0006] A method for preventing deadlocks in batch data writes based on primary key ordering includes: Step 1: Perform primary key extraction and type normalization on the set of records to be written to generate a normalized primary key string; Step 2: Perform primary key sorting based on the normalized primary key string to generate a logically ordered record sequence: Step 3: Perform intelligent batch sharding on the logically ordered record sequence to generate sharded record batches: Step 4: Based on the batch of sharded records, perform batch data writing according to the ordered arrangement logic, and perform adaptive adjustment of concurrency and backoff retries.

[0007] Optionally, step 1 includes: obtaining a set of records to be written, extracting the primary key field value from each record in the set of records to be written, and identifying the original data type of the primary key field value; performing the corresponding order-preserving normalization conversion on the identified original data type to uniformly convert the primary key field value into a lexicographically comparable normalized primary key string.

[0008] Optionally, primitive data types include object identifier types, universally unique identifier types, numeric types, string types, and composite primary key types.

[0009] Optionally, step 1 further includes: constructing a mapping table containing the association between the original records in the set of records to be written and their corresponding normalized primary key strings.

[0010] Optionally, step 2 includes: using the normalized primary key string as the sorting key, performing lexicographical ascending sort on the set of records to be written to generate a globally deterministic logically ordered sequence of records; by forcing a unified processing order of records before concurrent transactions perform batch writes, all concurrent transactions acquire database row locks in a physical order that is completely consistent with the logically ordered sequence of records, so as to release the circular wait conditions formed by deadlock and thereby proactively avoid lock contention conflicts.

[0011] Optionally, step 3 specifically involves: obtaining the current load characteristics, primary key density distribution, and historical deadlock occurrence rate within a preset statistical period, and dynamically calculating the optimal batch size of the current data write transaction based on the load characteristics, primary key density distribution, and historical deadlock occurrence rate to perform intelligent batch sharding processing on the logically ordered record sequence to generate sharded record batches.

[0012] Optionally, intelligent batch sharding is performed on the logically ordered record sequence to generate sharded record batches. Specifically, the logically ordered record sequence is physically split using the calculated optimal batch size to divide the logically ordered record sequence into multiple sharded record batches with time-sequence execution dependencies. This reduces the probability of lock overlap and shortens the lock holding time during transaction execution by dynamically adjusting the total amount of lock resources held by a single transaction.

[0013] Optionally, step 4 includes: loading each batch of sharded records into the database execution engine in the logically ordered sequence to perform batch update or insert operations; monitoring deadlock exception signals and transaction response latency in real time during execution; if the deadlock exception signal indicates that the deadlock occurrence rate exceeds a preset threshold, dynamically reducing the number of parallel transactions performing batch data writing to achieve dynamic peak shaving; if the deadlock exception signal indicates that a deadlock exception has been thrown, automatically triggering a randomized exponential backoff retry process, calculating an exponentially increasing waiting baseline time based on the retry count value and adding a random jitter factor to disperse the timing of concurrent retry requests in the time domain, so as to implement data persistence of the set of records to be written.

[0014] Optionally, the processor is used to run a computer-executable program to implement the steps of the above-described method for preventing deadlocks in batch data writes based on primary key ordering.

[0015] A batch data write deadlock prevention device based on primary key ordering includes: The first program unit is used to perform primary key extraction and type normalization processing on the set of records to be written in order to generate a normalized primary key string; The second program unit is used to perform primary key sorting based on the normalized primary key string to generate a logically ordered record sequence. The third program unit is used to perform intelligent batch sharding processing on the logically ordered record sequence to generate sharded record batches; The fourth program unit is used to perform batch data writing based on the ordered arrangement logic of the fragmented record batches, and to perform adaptive adjustment of concurrency and backoff retries.

[0016] The technical advantages of the technical solution provided in this application are: This application provides a batch data write deadlock prevention method based on primary key ordering. Addressing the high deadlock rate of traditional solutions mentioned in the background art due to the lack of a systematic lock acquisition order control mechanism, this method achieves absolute alignment of the locking order for all concurrent transactions by performing order-preserving normalization processing on different types of primary keys in step 1, combined with global ordered sorting in step 2. Compared to the traditional random locking mode, this application forces all transactions to acquire row locks in the same lexicographical ascending order, mathematically eliminating the possibility of a loop forming in the lock waiting chain. This reduces the deadlock rate from the original 15%-30% to a lower level, resolving the circular wait deadlock problem caused by overlapping lock acquisition orders in the background art.

[0017] Meanwhile, through the intelligent batch sharding mechanism in step 3, this application can dynamically calculate the optimal batch size based on real-time load and deadlock rate. This dynamic adjustment mechanism avoids the drawback of traditional fixed batch schemes that exacerbate lock contention due to excessively long lock holding time for a single transaction when processing massive amounts of data, effectively reducing the probability of collisions between transactions. Combined with the randomized exponential backoff retry logic in step 4, this application can disperse retry opportunities through a random factor when facing occasional lock timeouts or system jitter, avoiding the secondary impact of a "retry storm" on the database. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a method for preventing deadlocks in batch data writing based on primary key ordering, as described in an embodiment of this application.

[0019] Figure 2 This is a schematic diagram of a batch data writing deadlock prevention device based on primary key ordering, according to an embodiment of this application.

[0020] Figure 3 This is a schematic diagram of an electronic device structure according to an embodiment of this application. Detailed Implementation

[0021] like Figure 1 As shown, this application provides a method for preventing deadlocks in batch data writes based on primary key ordering, including: Step 1: Perform primary key extraction and type normalization on the set of records to be written to generate a normalized primary key string; Step 2: Perform primary key sorting based on the normalized primary key string to generate a logically ordered record sequence: Step 3: Perform intelligent batch sharding on the logically ordered record sequence to generate sharded record batches: Step 4: Based on the batch of sharded records, perform batch data writing according to the ordered arrangement logic, and perform adaptive adjustment of concurrency and backoff retries.

[0022] Optionally, step 1 includes: obtaining a set of records to be written, extracting the primary key field value from each record in the set of records to be written, and identifying the original data type of the primary key field value; performing the corresponding order-preserving normalization conversion on the identified original data type to uniformly convert the primary key field value into a lexicographically comparable normalized primary key string.

[0023] Optionally, primitive data types include object identifier types, universally unique identifier types, numeric types, string types, and composite primary key types.

[0024] Preferably, the specific implementation process of step 1 is as follows: First, obtain the set of records to be written. The set of records to be written consists of multiple business data records corresponding to the batch insert and update operation of the relational database. Each business data record contains a primary key field and a non-primary key field corresponding to the target database table structure. The primary key field is the field in the database table used to uniquely identify a single data record, and the non-primary key field is other business fields in the database table besides the primary key field. Traverse each business data record in the set of records to be written, and extract the primary key field value from each business data record that completely matches the primary key field name of the target database table. Establish a one-to-one mapping relationship between all the extracted primary key field values ​​and the corresponding business data records to ensure that in the subsequent processing, the business data records after normalization and sorting can accurately match the original primary key field values, and there will be no data misalignment or mismatch between primary keys and business data.

[0025] Preferably, in the specific technical implementation of step 1, after the primary key field value is extracted, a raw data type identification operation is performed on each extracted primary key field value. The raw data types include object identifier type, universally unique identifier type, numeric type, string type, and composite primary key type. During the type identification process, type matching is performed sequentially according to a preset priority order, from high to low: object identifier type, universally unique identifier type, numeric type, string type, and composite primary key type. Performing type matching according to this priority order can avoid identification conflicts between different data types and ensure that each primary key field value can be matched with a unique corresponding raw data type. After the type matching is completed, each primary key field value is marked with a matching raw data type identifier. This raw data type identifier will serve as the basis for subsequent order-preserving normalization conversion operations, ensuring that subsequent conversion operations can match the processing logic that is completely corresponding to the raw data type.

[0026] Preferably, in the specific technical implementation of step 1, after identifying the original data type of the primary key field value, for each original data type matching the primary key field value, a corresponding order-preserving normalization conversion operation is performed. The core principle of the order-preserving normalization conversion operation is that the lexicographical order of the converted string content is consistent with the business logic order of the original primary key field value itself, so as to ensure that subsequent sorting operations can accurately restore the original order logic of the primary key field value, providing a benchmark for the unified lock acquisition order; for primary key field values ​​whose original data type is object identifier, when performing the corresponding normalization conversion operation, the object identifier type primary key field value is converted into a fixed-length hexadecimal string, which is complete The system retains the timestamp, device process, and counter information contained in the original object identifier. The lexicographical order of the converted hexadecimal string is completely consistent with the generation sequence of the original object identifier, ensuring no order discrepancies. For primary key field values ​​whose original data type is a universally unique identifier, the corresponding normalization conversion operation converts the universally unique identifier type primary key field value into a standard format string. This standard format string fully retains all character information and format delimiter information of the original universally unique identifier, ensuring that the converted strings of different universally unique identifiers have a unique lexicographical comparison benchmark, preventing duplicate strings after conversion of different primary key field values.

[0027] Preferably, in the specific technical implementation of step 1, when performing the corresponding normalization conversion operation on the primary key field value whose original data type is numeric, a fixed numerical offset is first added to the negative numerical values ​​to convert all values ​​into values ​​within the positive range. Then, the converted positive numbers are uniformly padded with zeros to a string of fixed length. The fixed length setting can cover the character length of the maximum numerical value that the numeric type can support. After processing in this way, the lexicographical sorting result of the converted string of the numeric primary key field value is completely consistent with the size sorting result of the original numerical value, avoiding the problem of mismatch between numerical size and lexicographical order. When performing the corresponding normalization conversion operation on the primary key field value whose original data type is string, the string primary key field value is uniformly converted into a string with a fixed character encoding format. The fixed character encoding format can ensure that strings under different character sets have a unified comparison benchmark. At the same time, null values ​​and strings without content are uniformly converted into preset special marker strings. The lexicographical order of the special marker string is lower than that of all strings with normal business content, ensuring that null primary key field values ​​can be fixed at the first position in subsequent sorting, and there will be no problem of disordered sorting positions.

[0028] Preferably, in the specific technical implementation of step 1, when performing the corresponding normalization conversion operation on the primary key field value whose original data type is a composite primary key, the field value of each sub-field in the composite primary key is extracted sequentially according to the preset field order of the composite primary key. Then, for each sub-field value, the normalization conversion operation is performed by matching its corresponding data type to obtain the normalized substring corresponding to each sub-field. After that, using a preset non-printable cell separator, all normalized substrings are concatenated sequentially according to the field order of the composite primary key to obtain the complete normalized primary key string corresponding to the composite primary key. After processing in this way, the sorting logic of the composite primary key prioritizes sorting according to the normalization result of the first sub-field. If the content of the first sub-field is the same, it is then sorted according to the normalization results of subsequent sub-fields. This fully conforms to the business sorting logic of the composite primary key itself. At the same time, the non-printable cell separator will not cause content conflicts with the normal business string, which can ensure that the strings after conversion of different composite primary keys have a unique comparison benchmark.

[0029] Preferably, in the specific technical implementation of step 1, after completing the order-preserving normalization conversion of all primary key field values, a normalized primary key string corresponding to each primary key field value is obtained. All normalized primary key strings have a unified lexicographical order for comparison, and there are no issues of incomparability between different data types or comparison results not conforming to business logic. The normalized primary key strings obtained after conversion are subjected to duplicate checks. If duplicate normalized primary key strings are found, their corresponding original primary key field values ​​are matched for secondary checks to ensure that the normalized primary key strings corresponding to the unique primary key in the same database table are unique. After the checks are completed, a complete association mapping relationship is established between each normalized primary key string and the corresponding original business data record, original primary key field value, and original data type identifier. This association mapping relationship will be completely passed to subsequent sorting operations, batch sharding operations, and database execution operations to ensure that all subsequent operations use the normalized primary key string as a unified order benchmark, thereby ensuring that all concurrently executed batch insert and update operations can acquire database row locks in a completely consistent order, fundamentally eliminating the conditions for the formation of circular waits.

[0030] Preferably, in a scenario, when implementing step 1, corresponding degradation processing logic is set for boundary scenarios where the original data type recognition of the primary key field value fails or the normalization conversion operation fails to execute. When recognition failure or conversion failure occurs, the hash code value corresponding to the abnormal primary key field value is first obtained, and the hash code value is converted into a fixed-length numeric string. This fixed-length numeric string is used as the normalized primary key string corresponding to the primary key field value. This degradation processing logic can ensure that all primary key field values ​​can obtain the corresponding normalized primary key string, and there will be no problem that some data cannot be processed. At the same time, the fixed-length numeric string still has lexicographical comparability, which can ensure the normal execution of subsequent sorting operations and will not affect the execution stability of the entire batch operation due to the abnormality of a single data.

[0031] Preferably, in the specific technical implementation of step 1, the unified format normalized primary key string formed by the order-preserving normalization conversion operation provides a unique and definite sorting benchmark for all concurrent transactions. Unlike the traditional approach of directly using the original primary key value for unordered processing, this application ensures that the processing order for the same primary key set is completely consistent in different concurrent transactions through unified normalization processing. The sorting results will not differ due to different primary key data types or different business system processing logic. This processing method eliminates the core cause of inconsistent lock acquisition order among different concurrent transactions from the root, providing a core technical foundation for breaking the circular wait conditions caused by deadlocks. At the same time, it does not increase additional persistent storage overhead, and all operations can be completed through data processing in memory, with a low impact on the overall execution efficiency of batch operations.

[0032] Optionally, step 1 further includes: constructing a mapping table containing the association between the original records in the set of records to be written and their corresponding normalized primary key strings.

[0033] Preferably, the specific implementation process of step 1 is as follows: the mapping table construction operation is performed after the full primary key extraction of the record set to be written, the identification of the original data type of the primary key field value, and the order-preserving normalization conversion of all primary key field values ​​are completed. The association relationship between a single original record and its corresponding primary key field value output by the primary key extraction operation, and the normalized primary key string output by the order-preserving normalization conversion operation, together serve as the core inputs of the mapping table construction operation. The mapping table adopts a key-value pair storage structure, which can realize the fast matching and reading of a single original record and its corresponding normalized primary key string. This is different from the loose data processing mode without fixed association relationships in traditional solutions, and provides a unified association benchmark for subsequent full-process data processing.

[0034] Preferably, in the specific technical implementation of step 1, the key-value pair generation rules of the mapping table are clearly defined to ensure that each key-value pair can establish a unique and stable association between the original record and the corresponding normalized primary key string; the key of the mapping table is a single complete original record in the record set to be written, and the value of the mapping table is the unique normalized primary key string obtained after primary key extraction, original data type identification, and order-preserving normalization conversion of the original record; during the key-value pair generation process, each original record in the record set to be written is traversed sequentially, and the currently traversed original record is used as the key, and the normalized primary key string uniquely corresponding to the original record is used as the value, and written into the mapping table. The traversal process strictly follows the original traversal order of the record set to be written to avoid the problem of mismatch between the original record and the normalized primary key string.

[0035] Preferably, in the specific technical implementation of step 1, a uniqueness check is performed on each key-value pair written to the mapping table to ensure that the associations within the mapping table have the characteristics of being conflict-free and traceable. The uniqueness check processes the key-value pairs already written in the mapping table and the key-value pairs to be written. The check process is divided into two dimensions. The first dimension checks whether the original record key to be written already exists in the mapping table. If the original record key is duplicated, the latest normalized primary key string is directly overwritten to avoid redundant data in the mapping table. The second dimension checks whether the normalized primary key string value to be written is consistent with the normalized primary key string already stored in the same original record. If the same original record corresponds to multiple different normalized primary key strings, the exception information is recorded and the primary key normalization conversion process of the original record is re-executed to ensure a one-to-one correspondence between key-value pairs. The uniqueness check can avoid the problem of mismatch between the original record and the sorting key in the subsequent sorting process, providing a reliable comparison benchmark for the subsequent primary key ordered sorting.

[0036] Preferably, in one scenario, when implementing step 1, for the original record of the composite primary key type, the key-value pair generation rules of the mapping table are adapted to ensure that the association between the original record corresponding to the composite primary key and the normalized primary key string conforms to the business sorting logic of the composite primary key; for the original record containing the composite primary key, the type identification and normalization conversion of each sub-field are completed sequentially according to the preset field order of the composite primary key, and then the normalization results of all sub-fields are concatenated sequentially according to the field order of the composite primary key using a preset non-printable unit separator to obtain the complete normalized primary key string corresponding to the composite primary key; then, the original record containing the composite primary key is used as the key, and the concatenated complete normalized primary key string is used as the value, and written into the mapping table. At the same time, the sub-field information of the composite primary key and the normalization results of the corresponding sub-fields are recorded synchronously in the mapping table to provide traceable data support for subsequent optimization of the composite primary key sharding boundary.

[0037] Preferably, in the specific technical implementation of step 1, the constructed mapping table provides the core sorting benchmark for the subsequent primary key ordered sorting step, and establishes a traceable association between the sorting process and the original records. In the subsequent primary key ordered sorting step, the original records in the record set to be written are taken as the processing objects, and the normalized primary key string extracted from the mapping table and corresponding to each original record is taken as the sorting comparison benchmark. During the sorting process, the normalized primary key strings corresponding to any two original records can be quickly obtained through the mapping table, thereby completing the lexicographical order comparison operation. There is no need to repeatedly execute the primary key extraction and normalization conversion process, reducing the computational overhead of the sorting step. After sorting, the original primary key information and normalized primary key information corresponding to the ordered records can be traced back through the mapping table to ensure that the order of the sorted records is completely consistent with the lexicographical order of the normalized primary key strings, thus ensuring the uniformity of the lock acquisition order of all concurrent transactions from the root.

[0038] Preferably, in the specific technical implementation of step 1, for abnormal scenarios such as primary key normalization conversion failure and missing primary key fields in original records, corresponding degradation processing rules are set for the construction process of the mapping table to ensure the integrity of the mapping table and the executability of subsequent processes. For the original record that is abnormal, the abnormal information generated during the primary key normalization conversion is captured first, and then the primary key field value of the abnormal original record is hash encoded and converted into a fixed-length numeric string, which is used as the normalized primary key string corresponding to the abnormal original record. Then, the abnormal original record is used as the key, and the fixed-length numeric string obtained from the degradation processing is used as the value, and the key-value pair is marked as a degradation processing state in the mapping table. This provides data basis for subsequent abnormal monitoring and log recording. The degradation processing rules ensure that all original records to be written can establish corresponding associations in the mapping table, and the failure of the entire mapping table construction due to the abnormality of a single record will not cause the batch writing process to fail.

[0039] Preferably, in the specific technical implementation of step 1, a full consistency check is performed on the constructed mapping table to verify the matching degree between the association relationship in the mapping table and the set of records to be written, providing a reliable data foundation for subsequent full-process data processing. The processing objects of the consistency check are the constructed mapping table and the original set of records to be written. The check process is divided into two steps. The first step is to count the total number of key-value pairs in the mapping table and compare it with the total number of records in the set of records to be written to ensure that the two are completely consistent and there are no missing or redundant records. The second step is to extract a preset proportion of key-value pairs from the mapping table and re-execute the primary key extraction, original data type identification and order-preserving normalization conversion process of the corresponding original records. The regenerated normalized primary key string is compared with the normalized primary key string stored in the mapping table to ensure the accuracy of the association relationship. After the check passes, the mapping table is loaded into the memory cache for direct use in subsequent intelligent batch sharding, batch insert and update statement construction, and exception retry stages, realizing the full-process reuse of the primary key normalization result.

[0040] Optionally, step 2 includes: using the normalized primary key string as the sorting key, performing lexicographical ascending sort on the set of records to be written to generate a globally deterministic logically ordered sequence of records; by forcing a unified processing order of records before concurrent transactions perform batch writes, all concurrent transactions acquire database row locks in a physical order that is completely consistent with the logically ordered sequence of records, so as to release the circular wait conditions formed by deadlock and thereby proactively avoid lock contention conflicts.

[0041] Preferably, the specific implementation process of step 2 is as follows: After generating the normalized primary key strings corresponding to all original records in the record set to be written, the normalized primary key string uniquely corresponding to each original record in the mapping table constructed in step 1 is used as the sorting key to perform sorting processing on all original records in the record set to be written. The sorting processing adopts a stable sorting algorithm, and the sorting rule is lexicographical ascending order to ensure that the sorting result has global uniqueness and determinism, and will not cause inconsistencies in the sorting result due to differences in the input order of the original records or the execution sequence of concurrent transactions. The stable sorting algorithm can guarantee that multiple original records with the same normalized primary key string content maintain their original relative order before and after sorting, avoiding random fluctuations in the sorting result due to the instability of the sorting algorithm itself, and laying a deterministic benchmark for the unified record processing order and unified row lock acquisition order of all subsequent concurrent transactions.

[0042] Preferably, in the specific technical implementation of step 2, after completing the lexicographical ascending sorting process, a logically ordered record sequence corresponding to the set of records to be written is generated. All original records within the logically ordered record sequence are arranged strictly according to the lexicographical ascending order rule of the normalized primary key string. The logically ordered record sequence and the original set of records to be written have completely identical total number of records and data content. Only the arrangement order of the original records is adjusted, and no modification is made to the primary key field values ​​or non-primary key business field values ​​in the original records, to ensure the data integrity and business accuracy of subsequent batch write operations. The logically ordered record sequence has global determinism. For any concurrent transaction processing the same primary key set, regardless of the order of the original record inputs, after lexicographical ascending sorting according to the same rules, the arrangement order of the generated logically ordered record sequence is completely consistent. This is different from the random record processing order without fixed rules in traditional solutions, eliminating the core cause of inconsistent lock acquisition order from the data level.

[0043] Preferably, in the specific technical implementation of step 2, after generating the logically ordered record sequence, a full verification operation is performed on the sorting validity and consistency of the logically ordered record sequence to ensure that the sorting result conforms to the preset lexicographical ascending order rule and avoids the problem of order disorder caused by abnormal sorting process. The processing object of the verification operation is the generated logically ordered record sequence. The verification process traverses all adjacent record pairs in the logically ordered record sequence in sequence, extracts the normalized primary key strings corresponding to the previous record and the next record in each pair of adjacent records in turn, performs a lexicographical comparison on the two normalized primary key strings, and verifies whether the lexicographical order of the normalized primary key string of the previous record is less than or equal to the lexicographical order of the normalized primary key string of the next record. If an adjacent record pair that does not conform to the ascending order rule is found during the verification process, the corresponding error log is recorded, and the subsequent process is terminated and rolled back to the original set of records to be written. The lexicographical ascending order sorting process is re-executed until the generated logically ordered record sequence passes the full verification, ensuring the accuracy of the logically ordered record sequence and providing a reliable execution benchmark for the subsequent unified row lock acquisition order.

[0044] Preferably, in the specific technical implementation of step 2, all concurrent transactions must complete the primary key normalization and lexicographical ascending sorting of the corresponding set of records to be written before performing batch write operations. This forces a unified processing order of records in the target database table for all concurrent transactions. Regardless of the original input order of the set of records to be written received by the concurrent transactions, and regardless of the differences in the start time and execution progress of the concurrent transactions, all concurrent transactions use their own logically ordered record sequence as the sole processing order benchmark to perform batch write operations on the records in the target database table. This fundamentally eliminates the problem of inconsistent processing order of different concurrent transactions for the same primary key set. This processing method differs from the traditional batch write scheme, which directly processes records according to the original data receiving order. In the traditional mode, the record processing order of different concurrent transactions is completely random, which easily leads to overlapping lock acquisition orders. However, this application, through pre-sorting processing, completes the global unification of the processing order before the transaction enters the database execution stage, thus avoiding the possibility of lock order conflicts in the process.

[0045] Preferably, in the specific technical implementation of step 2, the arrangement order of the logically ordered record sequence directly determines the physical acquisition order of database row locks by concurrent transactions. Concurrent transactions strictly follow the record arrangement order within the logically ordered record sequence, performing batch write operations on each record sequentially, and then requesting row locks for the corresponding records from the database engine in an order completely consistent with the logically ordered record sequence. Upon receiving the lock request from a concurrent transaction, the database engine locks the corresponding records according to the request order, ensuring that the row lock request order for records with the same primary key by all concurrent transactions completely follows the lexicographical ascending order rule of the normalized primary key string, preventing any overlap or reversal of lock request orders. For multiple concurrent transactions with overlapping primary keys, all transactions will prioritize requesting row locks for the primary key with the earlier lexicographical order, and then sequentially request row locks for the primary keys with the later lexicographical order. Only after a transaction successfully acquires the row lock for the preceding primary key and completes the processing of the corresponding record will it initiate a row lock request for the subsequent primary key, ensuring that the row lock acquisition order remains completely consistent across all concurrent transactions.

[0046] Preferably, in the specific technical implementation of step 2, by unifying the row lock acquisition order of all concurrent transactions, the circular wait condition for deadlock formation is fundamentally eliminated, thereby enabling predictive avoidance of lock contention conflicts between concurrent transactions. The formation of deadlock requires the simultaneous satisfaction of mutual exclusion, hold and wait, non-preemption, and circular wait conditions. This application, by forcibly unifying the row lock acquisition order, ensures that the lock wait relationship of all concurrent transactions is always unidirectional, that is, only the row lock holder of the primary key record with the earlier lexicographical order is waited for by the subsequent transaction that applies for the row lock of the primary key record with the later lexicographical order, and there will be no closed-loop wait relationship where multiple transactions wait for each other's row locks. If multiple concurrent transactions perform operations on the same primary key set, only a one-way waiting scenario will occur, where the transaction that starts first acquires the row lock with the highest lexicographical order, and the transaction that starts later waits for the preceding transaction to release the corresponding row lock before acquiring it in sequence. This will not form a circular waiting chain between transactions. It achieves deadlock prevention from the necessary condition level of deadlock formation, which is different from the passive mode of traditional solutions that handle deadlocks by detection and rollback after they occur. It achieves proactive and predictive avoidance of lock contention conflicts.

[0047] Preferably, in one scenario, when implementing step 2, the corresponding sorting rules are adapted for the set of records to be written of the composite primary key type to ensure the consistency of the sorting of the logically ordered record sequence and the uniformity of the row lock acquisition order in the composite primary key scenario; for the original records containing the composite primary key, the complete normalized primary key string generated in step 1, which is composed of the normalized results of each subfield of the composite primary key, is used as the sorting key, and lexicographical ascending sort is performed, so that the records in the logically ordered record sequence are first arranged in ascending order according to the normalized result of the first subfield of the composite primary key. When the normalized results of the first subfield are the same, they are then arranged in ascending order according to the normalized results of the subsequent subfields, which fully conforms to the business sorting logic of the composite primary key itself and the database index sorting rules. This adaptation ensures that, in composite primary key scenarios, all concurrent transactions process the same composite primary key set in the same order. At the same time, it prioritizes sorting at the point where the value of the first subfield of the composite primary key changes, allowing related records under the same business dimension to be concentrated in adjacent positions of the logically ordered record sequence. This reduces the probability of cross-batch lock contention between different concurrent transactions and also leverages the locality principle of database indexes to improve the cache hit rate of batch write operations.

[0048] Preferably, in the specific technical implementation of step 2, the sorting operation is completed entirely in memory, without incurring additional persistent storage overhead. Furthermore, the time overhead of sorting is relatively low compared to the network transmission overhead and database execution overhead of batch write operations, and will not significantly affect the overall execution efficiency of batch write operations. After generating and verifying the logically ordered record sequence, the logically ordered record sequence is directly passed to the subsequent intelligent batch sharding and batch write statement construction stages. Subsequent stages strictly adhere to the arrangement order of the logically ordered record sequence when performing data processing and statement construction, ensuring that the processing order of records remains consistent throughout the entire process from sorting to database execution, preventing lock acquisition order anomalies caused by disordered order. The logically ordered record sequence will also serve as the execution benchmark for the subsequent intelligent batch sharding stage. The sharding operation only performs continuous splitting based on the logically ordered record sequence, without changing the relative order of records within each sub-batch after splitting. This ensures that each sub-batch after splitting still strictly follows the lexicographical ascending order rule of the normalized primary key string, thereby guaranteeing a consistent row lock acquisition order throughout the entire process.

[0049] Optionally, step 3 specifically involves: obtaining the current load characteristics, primary key density distribution, and historical deadlock occurrence rate within a preset statistical period, and dynamically calculating the optimal batch size of the current data write transaction based on the load characteristics, primary key density distribution, and historical deadlock occurrence rate to perform intelligent batch sharding processing on the logically ordered record sequence to generate sharded record batches.

[0050] Preferably, the specific implementation process of step 3 is as follows: After completing the generation and validity verification of the logically ordered record sequence, the logically ordered record sequence is used as the sole benchmark object for sharding processing. First, the core feature parameter collection operation required for sharding decision is performed. The core feature parameters include the current load characteristics, primary key density distribution, and historical deadlock occurrence rate within a preset statistical period. The current load characteristics are synchronously collected from the application service node running the current data write transaction and the target database node. The primary key density distribution is statistically generated based on the normalized primary key string within the logically ordered record sequence. The historical deadlock occurrence rate is extracted and statistically obtained from the preset database operation monitoring log and transaction execution log. The three types of core feature parameters serve as the basis for calculating the optimal batch size, ensuring that the final calculated batch size can adapt to the current operating environment, data distribution characteristics, and historical lock conflict situation. This differs from the fixed batch size processing mode in traditional solutions, fundamentally reducing the deadlock risk caused by excessively long single transaction lock holding time.

[0051] Preferably, in the specific technical implementation of step 3, multi-dimensional collection rules and normalization processing logic are set for the collection and quantification of current load characteristics to obtain load quantification indicators that can directly participate in the calculation of optimal batch size. The current load characteristics include two categories: the running load indicators of application service nodes and the running load indicators of target database nodes. The running load indicators of application service nodes include CPU utilization, memory utilization, and the proportion of active connections in the database connection pool. The running load indicators of target database nodes include database CPU utilization, IO wait time, and average transaction response time. Normalization processing is performed on the collected load indicators to convert the values ​​of each indicator into load quantification values ​​in the range of 0 to 1. Then, a comprehensive load characteristic value is obtained by weighted summation. The higher the comprehensive load characteristic value, the higher the overall running load of the current system. When calculating the optimal batch size, the upper limit of the batch size will be lowered accordingly to avoid the large-scale write operations in high-load scenarios from exacerbating system performance pressure and lock contention probability.

[0052] Preferably, in the specific technical implementation of step 3, the statistics and analysis of primary key density distribution are performed based on the normalized primary key strings within the logically ordered record sequence to obtain a density distribution index that reflects the distribution characteristics of the primary key. The statistical process of primary key density distribution first analyzes the interval span of the normalized primary key strings of adjacent records based on the lexicographical ascending order of the logically ordered record sequence, statistically analyzing the concentration of primary key values ​​within the global sorting interval, and simultaneously statistically analyzing the clustering degree of primary keys under the same business dimension. For composite primary key scenarios, it is also necessary to statistically analyze the number of records clustered with the same first primary key subfield. Based on the statistical results, a primary key density distribution index is generated. The higher the primary key density distribution index, the more concentrated the distribution of the primary key within the sorting interval, the smaller the primary key interval span of adjacent records, and the higher the potential probability of lock conflicts. The batch size will be adjusted accordingly when calculating the optimal batch size to avoid executing a large batch of records with highly clustered primary keys within the same transaction, thereby reducing the scope and duration of lock contention.

[0053] Preferably, in the specific technical implementation of step 3, the extraction and statistics of historical deadlock occurrence rate are performed based on the transaction execution logs and database deadlock monitoring logs within a preset statistical period to obtain a deadlock occurrence rate index that reflects historical lock conflict. The preset statistical period is a configurable sliding time window. From the logs within the sliding time window, the total number of transactions performing write operations on the same target database table and the number of transactions that experienced deadlock anomalies are extracted. The ratio of the number of transactions that experienced deadlock anomalies to the total number of transactions is used as the historical deadlock occurrence rate. The higher the historical deadlock occurrence rate, the higher the probability of lock conflicts and deadlocks in the current business scenario. When calculating the optimal batch size, the batch size will be reduced accordingly. By reducing the number of records in a single batch, the lock holding time of a single transaction is shortened, the probability of lock overlap between concurrent transactions is reduced, and data support is provided for subsequent adaptive adjustment of concurrency.

[0054] Preferably, in the specific technical implementation of step 3, based on the collected current load characteristics, primary key density distribution, and historical deadlock occurrence rate, dynamic calculation of the optimal batch size is performed to obtain the upper limit of the number of records in a single batch that is suitable for the current scenario. The calculation process of the optimal batch size first sets a baseline batch size as the basis for calculation, and then sets corresponding adjustment coefficients based on the comprehensive load characteristic value of the current load characteristics, the primary key density distribution index, and the historical deadlock occurrence rate. The baseline batch size is multiplied by each adjustment coefficient in turn to obtain the initial calculated batch size. Then, upper and lower limit thresholds are set for the initial calculated batch size to ensure that the final optimal batch size is between the preset minimum batch size and the maximum batch size. Among them, the adjustment coefficient corresponding to the historical deadlock occurrence rate has the highest priority. When the historical deadlock occurrence rate exceeds the preset first threshold, the baseline batch size is reduced by a preset ratio. When the historical deadlock occurrence rate exceeds the preset second threshold, the baseline batch size is directly halved. The value of the second threshold is higher than the value of the first threshold. By adjusting the deadlock occurrence rate with high priority, the changes in lock conflict risk are quickly responded to. At the same time, combined with the adjustment of load characteristics and primary key density distribution, the refined dynamic adaptation of the batch size is achieved.

[0055] Preferably, in the specific technical implementation of step 3, after completing the dynamic calculation of the optimal batch size, intelligent batch sharding is performed on the logically ordered record sequence based on the optimal batch size to generate multiple consecutive sharded record batches. The intelligent batch sharding strictly follows the lexicographical ascending order arrangement rule of the logically ordered record sequence, performs continuous sequential splitting on the logically ordered record sequence, and the number of records in each sharded record batch after splitting does not exceed the optimal batch size. Moreover, the records in each sharded record batch still maintain the original lexicographical ascending order arrangement and will not change the relative order of the records, ensuring that each sharded record batch still follows a unified row lock acquisition order when it is executed. During the splitting process, boundary checks are performed on the splitting position of the logically ordered record sequence. For composite primary key scenarios, splitting is preferentially performed at the position where the value of the first subfield of the composite primary key changes, ensuring that related records under the same business dimension are divided into the same sharded record batch as much as possible. This reduces the probability of lock contention across batches and can also utilize the locality principle of database indexes to improve the execution efficiency of batch write operations.

[0056] Preferably, in one scenario, when implementing step 3, corresponding verification rules and dynamic adjustment logic are set for the validity verification and adaptation adjustment after the generation of sharded record batches to ensure that the sharding results meet the execution requirements of the current scenario. After the sharded record batches are generated, the number of records in each sharded record batch is first verified to meet the limit of the optimal batch size, and the records in each sharded record batch are also verified to maintain the lexicographical ascending order. If the verification fails, the sharding process is re-executed. Then, based on the total number of generated sharded record batches, the parameters for subsequent adaptive adjustment of concurrency are adjusted in linkage. When the total number of sharded record batches is large, the upper and lower limits of the number of concurrent transactions are adjusted accordingly to achieve linkage adaptation between sharding size and concurrency. At the same time, for cases of abnormal primary key distribution or sudden changes in system load during the sharding process, a real-time recalculation mechanism is set. When the system load characteristics or deadlock monitoring data show a sudden change that exceeds the preset range, the sharding process is paused, the calculation of the optimal batch size is re-executed, and the sharding process of the remaining records is completed based on the updated optimal batch size, ensuring that the sharding results can adapt to the dynamic changes of the operating environment in real time.

[0057] Preferably, in the specific technical implementation of step 3, the generated batch of sharded records will serve as the smallest execution unit for subsequent batch write operations. Each batch of sharded records will be executed serially in the logically ordered record sequence. Only after each batch of sharded records is completed will the write transaction for the next batch of sharded records be started. This ensures that a single write transaction only holds the row locks corresponding to the records in the current batch of sharded records, and the lock holding time is only the write execution time of a single batch of records. This differs from the traditional large-scale write scheme where a single transaction holds row locks for all records and the lock holding time covers the execution time of all records. This significantly shortens the lock holding time of a single transaction, reduces the probability of overlapping lock resources between concurrent transactions, and further reduces the possibility of deadlock. At the same time, each batch of sharded records maintains a complete lexicographical ascending order, ensuring that the processing order of all concurrent transactions for the same primary key set remains consistent. This forms a complete technical cooperation with the core logic of primary key ordered sorting, jointly achieving deadlock risk prevention from two dimensions: lock acquisition order and lock holding time.

[0058] Optionally, intelligent batch sharding is performed on the logically ordered record sequence to generate sharded record batches. Specifically, the logically ordered record sequence is physically split using the calculated optimal batch size to divide the logically ordered record sequence into multiple sharded record batches with time-sequence execution dependencies. This reduces the probability of lock overlap and shortens the lock holding time during transaction execution by dynamically adjusting the total amount of lock resources held by a single transaction.

[0059] Preferably, the specific implementation process of intelligent batch sharding for logically ordered record sequences is as follows: the optimal batch size obtained by dynamic calculation is used as the sole execution benchmark for physical sharding operations, and the logically ordered record sequence after validity verification is used as the sole processing object for physical sharding operations; the physical sharding operation strictly follows the inherent lexicographical ascending order arrangement rule of the logically ordered record sequence, and only performs continuous sequential sharding on the logically ordered record sequence, without changing the relative arrangement order between any two records in the sequence, ensuring that within each batch of sharded records obtained after sharding, all records still maintain the complete lexicographical ascending order arrangement feature, forming a complete technical cooperation with the lock acquisition order control logic formed by the primary key ordered sorting stage, fundamentally ensuring that when all batches of sharded records are executed, they still follow the globally unified row lock acquisition order, and there will be no problem of lock acquisition order disorder due to sharding operations.

[0060] Preferably, after the physical splitting operation is completed, a time-series execution dependency relationship is constructed for all the split record batches. The time-series execution dependency relationship is defined according to the order of the split record batches in the original logically ordered record sequence. The preceding split record batch is the prerequisite execution dependency of the following split record batch. Only after the write transaction corresponding to the preceding split record batch has been fully executed and all held row lock resources have been released can the write transaction corresponding to the following split record batch be started. The construction of the time-series execution dependency relationship ensures that all split record batches after the same logically ordered record sequence is split will not be executed in parallel. This avoids multiple split transactions of the same batch of data holding row lock resources in different intervals at the same time, thereby reducing the scope of lock resource competition with other concurrent transactions and reducing the probability of lock circular wait from the execution sequence level.

[0061] Preferably, by constructing the physical partitioning operation and the time-series execution dependency relationship, the total amount of lock resources held by a single transaction can be dynamically adjusted. The total amount of lock resources held by a single transaction is directly related to the number of records in a single shard record batch, and the number of records in a single shard record batch is determined by the optimal batch size obtained by dynamic calculation. When the system load increases, the historical deadlock rate increases, and the primary key distribution concentration increases, the optimal batch size will be reduced accordingly, and the total amount of lock resources held by a single transaction will also decrease accordingly. A single write transaction only needs to hold the row lock resources corresponding to the records in the current shard record batch, without needing to hold the row lock resources corresponding to the entire logically ordered record sequence. This is different from the mode of single transaction locking the entire batch in the traditional large batch write scheme. From the perspective of lock resource holding scope, the lock contention boundary of a single transaction is narrowed, and the possibility of lock resource overlap between concurrent transactions is reduced.

[0062] Preferably, intelligent batch sharding effectively shortens the lock holding time during transaction execution. The row lock holding time for a single record is the complete duration from the request for the row lock to the transaction commit and release of the lock in the write transaction of the record batch to which the record belongs. In the traditional full batch write scheme, the row lock holding time for a single record covers the entire write execution process of the full record. However, after sharding, the row lock holding time for a single record is only the execution time of the batch to which it belongs. The row lock resources of the full data are split into multiple serially executed transactions and held separately, which greatly shortens the lock holding time of a single transaction. The shortening of the lock holding time directly reduces the probability of the overlap of lock resource time windows between concurrent transactions, which significantly reduces the possibility of different concurrent transactions holding conflicting row locks at the same time, further weakening the basic conditions for deadlock formation.

[0063] Preferably, in one scenario, when performing physical partitioning on a logically ordered sequence of records of composite primary key type, boundary optimization processing is performed on the partitioning position to adapt to the business sorting logic and lock contention characteristics of composite primary keys. During the boundary optimization process, the target partitioning position based on the optimal batch size is first determined. Then, within a preset range before and after the target partitioning position, the position where the value of the first subfield of the composite primary key changes is searched as the final partitioning point. If the position where the value of the first subfield changes is not found within the search range, the partitioning is performed using the original target partitioning position. Performing partitioning at the position where the value of the first subfield of the composite primary key changes can group related records under the same business dimension into the same batch of sharded records. This avoids the related data under the same business dimension being split into multiple parallel concurrent transactions, reducing the probability of lock contention across batches. It can also utilize the locality principle of database indexes to improve the cache hit rate of sharded batch write operations, further shortening the execution time of a single transaction and the lock holding time.

[0064] Preferably, after completing the physical partitioning and establishing the timing execution dependencies, a validity check is performed on all generated batches of partitioned records to ensure that the partitioning results meet the technical requirements for deadlock prevention. The validity check consists of three dimensions: the first dimension checks whether the number of records in each batch of partitioned records does not exceed the limit of the optimal batch size; the second dimension checks whether the records in each batch of partitioned records maintain a complete lexicographical ascending order; and the third dimension checks whether the timing execution dependencies of all batches of partitioned records are completely consistent with the order of the original logically ordered record sequence. If the check fails, the physical partitioning operation is re-executed until the generated batches of partitioned records pass the full-dimensional check. The batches of partitioned records that pass the check will serve as the smallest execution unit for subsequent batch write operations, and the total number of batches of partitioned records will serve as the core input parameter for the subsequent concurrency adaptive adjustment stage, realizing the linkage adaptation between the partition size and the number of concurrent transactions, and further balancing the system write throughput and the deadlock prevention effect.

[0065] Preferably, intelligent batch sharding processing and pre-processed primary key ordered sorting processing form a collaborative deadlock prevention system. Primary key ordered sorting processing breaks the circular waiting condition for deadlock formation at the lock acquisition order level, while intelligent batch sharding processing further weakens the basic conditions for deadlock formation at the lock holding range and lock holding duration levels. The two form a complementary technical cooperation rather than an isolated technical means. Unlike the traditional solution that only splits data by fixed shards, the intelligent batch sharding processing of this application dynamically adjusts the shard size based on the current load characteristics, primary key density distribution, and historical deadlock occurrence rate. It can adapt to changes in the operating environment in real time. In low load and low deadlock rate scenarios, the shard size can be appropriately increased to improve write throughput, while in high load and high deadlock rate scenarios, the shard size can be reduced to strengthen the deadlock prevention effect. It achieves a dynamic balance between throughput and stability, while maintaining a globally unified lock acquisition order throughout the process, and will not introduce new lock order conflict risks due to sharding operations.

[0066] Preferably, during the serial execution of sharded record batches, a real-time recalculation and dynamic adjustment mechanism for the shard size is set up to cope with scenarios such as sudden changes in system load and deadlock anomalies during execution. After each sharded record batch is executed, the current system load characteristics and the latest deadlock occurrence are re-collected, and the optimal batch size is updated in real time. If the updated optimal batch size deviates from the original calculated value beyond a preset range, the remaining unexecuted logically ordered record sequence is physically split again based on the updated optimal batch size to generate new sharded record batches and corresponding temporal execution dependencies. This mechanism ensures that the shard size always adapts to the current system operating state, avoiding the problem of mismatch between the shard size and the actual scenario due to sudden changes in the environment during execution, which could lead to excessively long lock holding time and increased lock conflict probability, thus ensuring the stability of the deadlock prevention effect throughout the entire process.

[0067] Optionally, step 4 includes: loading each batch of sharded records into the database execution engine in the logically ordered sequence to perform batch update or insert operations; monitoring deadlock exception signals and transaction response latency in real time during execution; if the deadlock exception signal indicates that the deadlock occurrence rate exceeds a preset threshold, dynamically reducing the number of parallel transactions performing batch data writing to achieve dynamic peak shaving; if the deadlock exception signal indicates that a deadlock exception has been thrown, automatically triggering a randomized exponential backoff retry process, calculating an exponentially increasing waiting baseline time based on the retry count value and adding a random jitter factor to disperse the timing of concurrent retry requests in the time domain, so as to implement data persistence of the set of records to be written.

[0068] Preferably, the specific implementation process of step 4 is as follows: After completing the intelligent batch sharding processing of the logically ordered record sequence and generating all sharded record batches, strictly following the inherent lexicographical ascending order arrangement rule of the logically ordered record sequence and the preset time-series execution dependency relationship between each sharded record batch, each sharded record batch is loaded into the execution engine of the target relational database in sequence to perform batch insert or update operations; the batch insert or update operation is implemented using the database-supported insert-if-exist-update syntax. When constructing the execution statement, the parameter sequence is organized completely according to the record arrangement order within the sharded record batch to ensure that the database execution engine's processing order of records is completely consistent with the arrangement order of the logically ordered record sequence, thereby ensuring that the transaction's acquisition order of database row locks is completely matched with the primary key ordered sorting rule, and no new lock acquisition order conflict risk is introduced due to disordered statement construction or parameter organization order.

[0069] Preferably, in the specific technical implementation of step 4, during the entire process of batch insert or update operations of sharded record batches, the database running status and transaction execution indicators are monitored in real time. The monitoring objects include two core indicators: deadlock exception signals and transaction response latency. Deadlock exception signals are collected in real time from the database engine's deadlock monitoring logs and transaction execution exception capture links. The collected content includes the transaction identifier where the deadlock occurred, the range of primary keys involved, and the time of the deadlock occurrence. Based on the collected deadlock exception signals, the current deadlock occurrence rate is calculated in real time within a preset sliding statistical window. Transaction response latency is collected from the database execution engine's transaction lifecycle monitoring links. The collected content includes the lock acquisition waiting time of a single sharded transaction, the statement execution time, and the total transaction commit time. Based on the collected transaction response latency data, the average response latency and latency fluctuation of the current batch write operation are statistically analyzed in real time. The monitoring results of deadlock exception signals and transaction response latency will serve as the core execution basis for subsequent dynamic adjustment of concurrency and triggering of abnormal retry processes.

[0070] Preferably, in the specific technical implementation of step 4, based on the deadlock anomaly signal obtained from real-time monitoring, when the calculated deadlock occurrence rate exceeds a preset threshold, a dynamic reduction operation of the number of parallel transactions is automatically executed to achieve dynamic peak shaving of batch data write traffic. The preset threshold sets a multi-tiered judgment rule, corresponding to different levels of concurrency reduction strategies. When the deadlock occurrence rate exceeds the first-tier threshold, a fixed-step reduction is performed on the number of parallel transactions currently executing batch data writes. When the deadlock occurrence rate exceeds the second-tier threshold, a halving reduction is performed on the number of parallel transactions currently executing batch data writes. The value of the second-tier threshold is higher than the value of the first-tier threshold. A lower limit threshold is set in the process of reducing the number of parallel transactions to ensure that the number of parallel transactions after reduction is not lower than the preset minimum concurrency, avoiding a significant drop in system write throughput due to excessive reduction in concurrency. At the same time, the adjustment of the number of parallel transactions is linked with the execution process of sharded record batches. Only after the currently executing sharded transaction is committed will the execution of subsequent sharded record batches be scheduled according to the adjusted concurrency, without interrupting the currently executing transactions, thus avoiding additional transaction rollback and data consistency risks.

[0071] Preferably, in the specific technical implementation of step 4, based on the deadlock exception signal obtained from real-time monitoring, when a deadlock exception thrown by the database engine is captured, a randomized exponential backoff retry process is automatically triggered. First, a complete rollback is performed on the transaction that currently experiences a deadlock exception, releasing all lock resources held by the transaction. Then, a retry count value is initialized. The retry count value is used to record the number of times the current transaction has been retried. At the same time, a maximum number of retryes is set to avoid system resource occupation caused by unlimited retries. Before each retry, an exponentially increasing waiting baseline time is calculated based on the current retry count value. The waiting baseline time increases exponentially with the increase of the retry count value. The more retries, the longer the corresponding waiting baseline time. By increasing the waiting time exponentially, the probability of multiple conflicting transactions retrying simultaneously in high-concurrency scenarios is gradually reduced, reducing the possibility of lock conflicts in the retry process.

[0072] Preferably, in the specific technical implementation of step 4, after calculating the exponentially increasing waiting baseline duration, a random jitter factor is added to the waiting baseline duration to disperse the triggering timing of concurrent retry requests in the time domain. The random jitter factor is a randomly generated value within a preset value range. After adding the waiting baseline duration and the random jitter factor, the final actual waiting duration is obtained. The actual waiting durations corresponding to different transactions and different retries are different, and the problem of multiple conflicting transactions retrying at the same time and causing a secondary deadlock will not occur when they use fixed delay retries. Unlike the retry storm problem that is easily caused by traditional fixed delay retry schemes, by dispersing the retry timing through the random jitter factor, the retry requests of multiple conflicting transactions can be completely staggered in the time domain, which greatly reduces the probability of lock conflicts in the retry process and improves the retry success rate after deadlock anomalies.

[0073] Preferably, in the specific technical implementation of step 4, after the waiting time is completed, the batch insertion or update operation of the corresponding shard record batch is re-initiated according to the same rules as the first execution. During the retry process, the lexicographical ascending order of the logically ordered record sequence is still strictly followed to ensure that the row lock acquisition order of the retry transaction is completely consistent with other concurrent transactions, and no new deadlock risk is introduced due to the change in the record processing order caused by the retry operation. After each retry execution, the retry count is incremented. If the retry execution is successful, the data persistence of the corresponding shard record batch is completed, and the execution of subsequent shard record batches is scheduled. If the retry triggers a deadlock exception again, it is determined whether the currently incremented retry count exceeds the maximum number of retryes. If it does not exceed the maximum number of retryes, the waiting base time and random jitter factor are recalculated, and the next round of retry is executed. If the maximum number of retryes is exceeded, an error log is recorded and an exception is thrown, terminating the execution of the current shard batch, so as to avoid abnormal retry continuously occupying system resources.

[0074] Preferably, in one scenario, when implementing step 4, the deadlock anomaly signal and transaction response latency data obtained from real-time monitoring are synchronously fed back to the front-end intelligent batch sharding stage, forming a dynamic adaptation closed loop throughout the entire process. When the deadlock occurrence rate continues to exceed the preset threshold, or the transaction response latency continues to rise, in addition to reducing the number of parallel transactions, the optimal batch size will be recalculated synchronously. The remaining unexecuted logically ordered record sequences will be re-executed with intelligent batch sharding to reduce the record size of a single shard record batch and further shorten the lock holding time of a single transaction. The lock holding range, lock holding duration, and number of concurrent transactions will be adjusted synchronously to quickly reduce the probability of deadlock. At the same time, for shard record batches in composite primary key scenarios, the rationality of the sharding position will be checked first in the retry process. If the related data of the same business dimension is split into multiple concurrently executed shard batches, the boundary optimization sharding will be re-executed for the remaining unexecuted shard record batches to reduce the risk of lock contention across shards.

[0075] Preferably, in the specific technical implementation of step 4, after the batch insertion or update operation of the sharded record batch is completed, the data corresponding to all successfully executed sharded record batches is persistently confirmed. This verifies whether the data written to the database is consistent with the original records in the logically ordered record sequence, ensuring the integrity and accuracy of the data writing. For sharded record batches that have triggered deadlock retries during execution, the uniqueness of the primary key and the accuracy of the business fields are additionally verified during persistent confirmation to avoid data duplication or field update errors during retries. At the same time, the deadlock occurrence, retry execution results, and transaction response latency data of the entire process are written to the monitoring log, providing data support for the calculation of historical deadlock occurrence rates in subsequent statistical periods and providing a basis for the continuous optimization of the batch write strategy. Together with the primary key ordered sorting, intelligent batch sharding, and concurrency adaptive adjustment, this forms a complete deadlock prevention technology system. On the basis of ensuring the accuracy of data persistence, it reduces the probability of deadlock from the root and improves the system stability and throughput in high-concurrency batch write scenarios.

[0076] In this application, real-time monitoring of deadlock anomaly signals and transaction response latency is implemented during execution. The real-time monitoring system is the decision-making basis for batch write deadlock prevention and control. It adopts a dual-link embedded monitoring architecture that combines application layer and database kernel capabilities, covering the entire lifecycle of sharded batches from loading the database engine to transaction commit / rollback. Without significantly increasing the database execution overhead, it provides millisecond-level accurate decision-making basis for subsequent concurrency adjustment and abnormal retries, while realizing the pre-identification of lock contention risks.

[0077] Real-time deadlock anomaly signal acquisition employs a dual-link complementary approach to avoid missing deadlock events due to a single acquisition link. The first link is the application-layer real-time anomaly capture link. Through the anomaly interception mechanism of database access frameworks such as JDBC, it captures data access anomalies of deadlock failures thrown by the database engine in real time. It extracts core information such as the transaction ID where the deadlock occurred, the range of primary keys involved, the deadlock timestamp, and the transaction rollback status from the anomaly stack. Each captured deadlock event is pushed to the monitoring and statistics module in real time, achieving millisecond-level detection of deadlock anomalies. The second link is the database kernel deadlock log retrieval link. Through the database's native system tables and deadlock monitoring log round-robin reading capabilities, it periodically retrieves all deadlock events within a preset sliding window, supplementing information on cross-service and cross-node concurrent transaction deadlocks not captured by the application layer, ensuring the completeness of deadlock event statistics.

[0078] Real-time deadlock rate calculation employs a sliding time window mechanism to ensure the real-time nature and accuracy of the statistical results. First, a configurable sliding statistical window is preset, continuously accumulating two core metrics: the total number of batch write transactions initiated within the window, and the number of transactions triggering deadlock anomalies within the window. The ratio of deadlocked transactions to the total number of transactions is used as the current real-time deadlock rate. The window continuously slides and updates over time, refreshing the statistical results after each batch of shards is executed. Simultaneously, deadlock events collected from both links are deduplicated to avoid duplicate counting of the same deadlock event, thus preventing calculation errors and ensuring that the statistical results accurately reflect the current level of lock contention.

[0079] Transaction response latency monitoring employs a full lifecycle tracking approach, breaking it down into multiple sub-dimension latency metrics. This not only reflects overall execution performance but also accurately identifies the risk level of lock contention. Latency monitoring consists of four core tracking points: First, transaction initiation latency, recording the time difference from shard batch commit to the database engine receiving the request, reflecting network transmission and database connection pool scheduling overhead; second, lock wait latency, recording the time difference from the transaction initiating row lock request to successfully acquiring the row lock, a core indicator reflecting the intensity of lock contention and directly related to the risk of deadlock; third, statement execution latency, recording the time difference from acquiring the row lock to the completion of the SQL statement execution, reflecting the database engine's write execution overhead; and fourth, total transaction response latency, recording the time difference from the transaction initiation request to the completion of the entire process of transaction commit / rollback, serving as a core evaluation metric for the overall performance of batch writes.

[0080] Real-time processing and risk prediction of latency data are important extensions of the monitoring system. For latency data collected in each batch of shards, outlier filtering is first performed to remove outliers caused by temporary network jitter or single-point database failures. Then, based on a sliding window, the average response latency, P95 / P99 percentile, and latency volatility of the current batch of writes are calculated. When the proportion of lock wait latency to total transaction response latency exceeds a preset threshold, or when latency volatility increases significantly, even if no actual deadlock has occurred, this risk signal will be synchronized to the concurrency adjustment module. This proactively predicts the trend of escalating lock contention, achieving preemptive prevention of deadlock risk, rather than passively responding only after a deadlock occurs.

[0081] The closed-loop storage and feedback of monitoring data enables seamless linkage across the entire process of monitoring, decision-making, and optimization. All collected deadlock anomaly signals and detailed latency metrics are written to the memory cache in real time for use by decision-making modules for concurrency adjustment and retry triggering, while simultaneously being asynchronously persisted to the monitoring log system. On one hand, real-time data provides a basis for dynamic strategy adjustments in the current write process; on the other hand, the persisted historical data serves as input parameters for calculating the optimal batch size and baseline concurrency of subsequent batch write tasks, continuously optimizing deadlock prevention strategies and providing comprehensive traceability data support for business problem investigation and strategy iteration optimization.

[0082] In this application, the dynamic peak-shaving process when the deadlock incidence rate exceeds a threshold is based on the core logic of dynamically reducing the number of parallel transactions writing batch data, thereby reducing the intensity of lock contention among concurrent transactions and fundamentally reducing the necessary conditions for deadlock formation. This process differs from the fixed concurrency handling mode of traditional solutions. It achieves fine-grained concurrency adjustment based on a multi-tiered threshold of real-time deadlock incidence, rapidly shrinking the concurrency scale when the deadlock risk increases and smoothly recovering it after the risk decreases, thus achieving a dynamic balance between system write throughput and operational stability.

[0083] The execution basis of dynamic peak shaving is a pre-defined three-level progressive deadlock incidence threshold system, corresponding to different levels of lock contention risk and differentiated peak shaving strategies. The first level is the warning threshold, corresponding to low deadlock risk; when the deadlock incidence rate exceeds this threshold, mild peak shaving is triggered. The second level is the risk threshold, corresponding to medium deadlock risk; when this threshold is exceeded, moderate peak shaving is triggered. The third level is the emergency threshold, corresponding to high deadlock risk; when this threshold is exceeded, severe peak shaving is triggered. Simultaneously, a hysteresis range is set for each threshold level to avoid frequent adjustments in concurrency caused by small fluctuations in the deadlock incidence rate around the threshold, ensuring the smooth operation of the batch write process.

[0084] Multi-tiered dynamic concurrency reduction is the core execution step of dynamic peak shaving, implementing differentiated reduction strategies for different risk levels. When the deadlock rate exceeds the warning threshold, mild peak shaving is performed, reducing the number of current parallel transactions in fixed steps, only slightly shrinking the concurrency to control deadlock risk while minimizing the impact on write throughput. When the deadlock rate exceeds the risk threshold, moderate peak shaving is performed, reducing the number of current parallel transactions by a preset ratio to quickly narrow the overall scope of lock contention and curb the upward trend of the deadlock rate. When the deadlock rate exceeds the emergency threshold, severe peak shaving is performed, directly halving the number of current parallel transactions to shrink the concurrency scale to the greatest extent, quickly alleviating the intense competition for lock resources and preventing the widespread spread of deadlocks that could cause a system throughput collapse.

[0085] The execution sequence of dynamic peak shaving employs a non-intrusive, smooth transition approach of "ending out old transactions and limiting new transactions," ensuring that peak shaving operations do not cause data consistency risks or execution interruptions. The reduction in concurrency does not forcibly interrupt ongoing sharded transactions, avoiding unnecessary transaction rollbacks and data anomalies. Specifically, the adjusted concurrency target value is locked first, and the ongoing sharded transactions are allowed to complete their commits or rollbacks naturally before subsequent sharded batches are scheduled according to the adjusted target concurrency. For example, if the current concurrency is 16 and the target concurrency after peak shaving is 8, the currently executing transactions will gradually release resources, and subsequent new transactions will only be scheduled until the concurrency reaches 8, achieving a smooth transition in the peak shaving process without interfering with ongoing write operations.

[0086] The gradual recovery mechanism after peak shaving is a key design feature to avoid the risk of secondary deadlocks caused by a rapid rebound in concurrency. When the real-time deadlock rate within the sliding window falls below the threshold, the concurrency is not immediately restored to its initial value. Instead, a gradual step-by-step increase strategy is adopted, adding only a fixed step size of concurrent transactions within each statistical period. After each increase in concurrency, a corresponding observation window is set. If the deadlock rate and lock wait latency do not increase within the observation window, the next increase continues. If a rebound in the deadlock rate occurs, the increase is immediately stopped, and the concurrency may even revert to the previous stage, ensuring a smooth and controllable recovery process and preventing further escalation of lock contention.

[0087] The coordinated optimization of dynamic peak shaving and intelligent batch sharding strategies achieves dual-dimensional collaborative prevention and control of deadlock risks. While performing concurrency shaving, real-time deadlock incidence data is synchronized to the intelligent batch sharding module, triggering a recalculation of the optimal batch size. When the deadlock incidence exceeds a threshold, the record size of a single shard batch is simultaneously reduced while concurrency is decreased, further shortening the lock holding time of a single transaction and reducing the scope of lock resources held by a single transaction, creating a synergistic effect with concurrency shaving. For example, during severe peak shaving, while concurrency is halved, the optimal batch size of a single batch is simultaneously reduced, addressing both concurrency and single-transaction lock granularity simultaneously to more quickly reduce the probability of deadlock.

[0088] Dynamic peak shaving with boundary control and observability design ensures the controllability and traceability of the peak shaving process. To prevent excessive drop in system write throughput due to peak shaving operations, an insurmountable minimum concurrency limit is set for the number of parallel transactions. Regardless of the deadlock rate, the concurrency will not fall below this limit, ensuring the system has basic write processing capabilities. Simultaneously, the entire peak shaving process, concurrency values ​​before and after adjustment, deadlock rate changes, and shard size adjustments are all fully recorded in the monitoring log, achieving end-to-end traceability of the peak shaving process and facilitating subsequent strategy optimization and troubleshooting.

[0089] In this application, the randomized exponential backoff retry process triggered by deadlock exceptions, along with the triggering of the retry process and the pre-transaction cleanup, are fundamental to ensuring the effectiveness of retry. This retry process only triggers deadlock exceptions explicitly thrown by the database engine and does not retries for non-deadlock exceptions such as primary key conflicts, SQL syntax errors, or database connection timeouts, thus avoiding data anomalies and system resource waste caused by invalid retries. When the application layer catches a deadlock exception, it first performs a complete transaction rollback operation to ensure that all lock resources held by the currently deadlocked transaction, such as row locks, gap locks, and insert intention locks, are completely released, eliminating lock wait relationships between this transaction and other concurrent transactions, and preventing residual lock resources from causing deadlocks to occur again in subsequent retries.

[0090] The initialization of core retry parameters provides standardized control rules for the retry process. After transaction rollback is completed, four core control parameters are initialized: first, the maximum number of retries, a preset fixed value used to limit system resource consumption and business execution blockage caused by unlimited retries; second, the current retry count, initialized to 0 and incremented by 1 after each retry execution, used to control the growth of exponential backoff time; third, the base backoff time, the minimum waiting benchmark for a single retry, which is the basic unit for exponential backoff calculation; and fourth, the random jitter interval, a preset numerical range used to generate a random jitter factor to stagger and disperse retry timing.

[0091] The exponentially increasing baseline waiting time is the core logic behind the retry process's reduction of the probability of secondary deadlocks. The baseline waiting time uses an exponential backoff calculation rule, using the base backoff time as the base and the current retry count as the exponent, ensuring that the more retries there are, the longer the baseline waiting time becomes. Its core principle is that as the number of retries increases, the retry interval between conflicting transactions is gradually lengthened, giving other concurrent transactions sufficient execution windows. This disperses the execution order of conflicting transactions in terms of time, significantly reducing the probability of multiple conflicting transactions simultaneously competing for lock resources again. This design differs from the traditional fixed-delay retry model, preventing conflicting transactions from initiating requests again after the same delay, thus fundamentally reducing the possibility of secondary deadlocks.

[0092] The superposition and staggered implementation of random jitter factors are key optimization designs to avoid "retry storms." After calculating an exponentially large baseline waiting time, an independently generated random jitter factor is superimposed on it. The random jitter factor is randomly generated from a preset numerical range. The final actual waiting time is obtained by superimposing the baseline waiting time and the random jitter factor. Since the random jitter factor for each deadlock transaction and each retry is independently and randomly generated, even if multiple transactions trigger deadlock retries at the same time, the final actual waiting time will vary significantly. This completely disperses the triggering timing of concurrent retry requests in the time domain, preventing multiple conflicting transactions from simultaneously initiating retries after a fixed delay, thus avoiding a lock contention cycle and secondary deadlock.

[0093] The pre-consistency check after the retry wait is a crucial step in ensuring that retry execution does not introduce new risks. After the wait period ends, retry execution is not initiated immediately. Instead, two core checks are performed first: First, the connection and running status of the target database table are checked to ensure normal database service and prevent retry failures due to underlying database faults. Second, the integrity and sorting consistency of the records in the current shard batch are checked to ensure that the logically ordered record sequence is still strictly arranged in ascending lexicographical order during retries. This guarantees that the row lock acquisition order of retry transactions is completely consistent with other concurrent transactions, preventing retry operations from changing the record processing order and introducing new deadlock risks.

[0094] The entire retry execution process ensures consistency, guaranteeing that retry actions do not disrupt the global deadlock prevention system. After successful verification, the corresponding shard batch UPSERT operation is re-initiated. The entire retry execution process strictly adheres to the same processing rules as the initial execution: it uses the exact same primary key sorting result as the initial execution to ensure the record processing order remains unchanged; it follows the same SQL statement construction rules to ensure the database execution logic remains unchanged; and it synchronously monitors deadlock anomaly signals and transaction response latency during retry execution, ensuring the retry process is also included in the overall monitoring system. Furthermore, retryed transactions are logged with the number of retries and the triggering reason, enabling full traceability of the retry process.

[0095] Successful retry handling and process advancement ensure the continuity of the overall batch write process. If the retry is successful, the transaction is committed normally, completing the data persistence of the corresponding shard batch. Successful retry log information is recorded, and the duration, number of retryes, and execution results are synchronized to the monitoring and statistics module for subsequent deadlock recovery success rate statistical analysis. Simultaneously, the retry count for the current shard batch is reset, and the write operations for subsequent shard batches are scheduled according to the time sequence, ensuring that a single batch retry does not affect the overall write process.

[0096] The retry termination and fallback mechanism prevents invalid retries from continuously consuming system resources. If a retry triggers a deadlock exception again, the current retry count is incremented by 1, and it is checked whether the incremented retry count exceeds the preset maximum number of retries. If it does not exceed the maximum number of retries, a new exponential wait baseline duration and random jitter factor are recalculated, and the next round of waiting and retries is executed. If the maximum number of retries has been exceeded, the retry process is immediately terminated, a critical error log is recorded containing detailed information about the deadlock transaction, the primary key range involved, the number of retries, and the exception information for each retry, and a business exception is thrown, notifying the upper-level business system for manual intervention and fallback handling. This prevents unlimited retries from continuously consuming database connections and system resources, causing overall business process blockage.

[0097] like Figure 2 As shown, this application provides a batch data write deadlock prevention device based on primary key ordering, comprising: The first program unit is used to perform primary key extraction and type normalization processing on the set of records to be written in order to generate a normalized primary key string.

[0098] The second program unit is used to perform primary key sorting based on the normalized primary key string to generate a logically ordered record sequence.

[0099] The third program unit is used to perform intelligent batch sharding processing on a logically ordered sequence of records to generate a batch of sharded records.

[0100] The fourth program unit is used to perform batch data writing based on the ordered arrangement logic of the fragmented record batches, and to perform adaptive adjustment of concurrency and backoff retries.

[0101] like Figure 3 As shown, this application provides an electronic device, including a memory and a processor; the memory stores a computer-executable program; the processor is used to implement the steps of the above-described batch data write deadlock prevention method based on primary key ordering when running the computer-executable program.

[0102] Figures 2-3 For an exemplary description, please refer to the above. Figure 1 .

Claims

1. A bulk data write deadlock prevention method based on primary key ordering, characterized by, include: Step 1: Perform primary key extraction and type normalization on the set of records to be written to generate a normalized primary key string; Step 2: Perform primary key sorting based on the normalized primary key string to generate a logically ordered record sequence: Step 3: Perform intelligent batch sharding processing on the logically ordered record sequence to generate sharded record batches: Step 4: Based on the batch of fragmented records, perform batch data writing according to the ordered arrangement logic and perform adaptive adjustment of concurrency and backoff retry.

2. The method for preventing deadlock in batch data writing based on primary key ordering as described in claim 1, characterized in that, Step 1 includes: Obtain the set of records to be written, extract the primary key field value from each record in the set of records to be written, and identify the original data type of the primary key field value; perform the corresponding order-preserving normalization conversion on the identified original data type to uniformly convert the primary key field value into a lexicographically comparable normalized primary key string.

3. The method for preventing deadlock in batch data writing based on primary key ordering according to claim 2, characterized in that, The primitive data types include object identifier type, universally unique identifier type, numeric type, string type, and composite primary key type.

4. The method for preventing deadlock in batch data writing based on primary key ordering as described in claim 1, characterized in that, Step 1 further includes: constructing a mapping table containing the association between the original records in the set of records to be written and the corresponding normalized primary key strings.

5. The method for preventing deadlock in batch data writing based on primary key ordering according to claim 1, characterized in that, Step 2 includes: Using the normalized primary key string as the sorting key, the set of records to be written is sorted in ascending lexicographical order to generate a globally deterministic logically ordered sequence of records. By forcing a unified processing order of records before concurrent transactions perform batch writes, all concurrent transactions acquire database row locks in a physical order that is completely consistent with the logically ordered sequence of records, thereby resolving the circular wait conditions caused by deadlocks and proactively avoiding lock contention conflicts.

6. The method for preventing deadlock in batch data writing based on primary key ordering according to claim 1, characterized in that, Step 3 specifically involves: The system acquires the current load characteristics, primary key density distribution, and historical deadlock rate within a preset statistical period. Based on these characteristics, the primary key density distribution, and the historical deadlock rate, it dynamically calculates the optimal batch size for the current data write transaction to perform intelligent batch sharding on the logically ordered record sequence to generate sharded record batches.

7. The method for preventing deadlock in batch data writing based on primary key ordering according to claim 1, characterized in that, The logically ordered record sequence is subjected to intelligent batch sharding to generate sharded record batches. Specifically, the logically ordered record sequence is physically divided using the calculated optimal batch size to divide the logically ordered record sequence into multiple sharded record batches with time-series execution dependencies. This reduces the probability of lock overlap and shortens the lock holding time during transaction execution by dynamically adjusting the total amount of lock resources held by a single transaction.

8. The method for preventing deadlock in batch data writing based on primary key ordering according to claim 1, characterized in that, Step 4 includes: According to the logically ordered record sequence, each batch of fragmented records is sequentially loaded into the database execution engine to perform batch update or insert operations. During execution, deadlock exception signals and transaction response latency are monitored in real time. If the deadlock exception signal indicates that the deadlock occurrence rate exceeds a preset threshold, the number of parallel transactions executing the batch data write is dynamically reduced to achieve dynamic peak shaving. If the deadlock exception signal indicates that a deadlock exception is thrown, a randomized exponential backoff retry process is automatically triggered. The waiting baseline time is calculated exponentially based on the retry count value and a random jitter factor is added to disperse the timing of concurrent retry requests in the time domain in order to implement data persistence of the set of records to be written.

9. A batch data write deadlock prevention device based on primary key ordering, characterized in that, include: The first program unit is used to perform primary key extraction and type normalization processing on the set of records to be written in order to generate a normalized primary key string; The second program unit is used to perform primary key sorting processing based on the normalized primary key string to generate a logically ordered record sequence. The third program unit is used to perform intelligent batch sharding processing on the logically ordered record sequence to generate a batch of sharded records. The fourth program unit is used to perform batch data writing based on the batch of fragmented records in an ordered arrangement logic, and to perform adaptive adjustment of concurrency and backoff retry.

10. An electronic device, characterized in that, The method includes a memory and a processor, wherein the memory stores a computer-executable program, and the processor is used to run the computer-executable program to implement the batch data write deadlock prevention method based on primary key ordering as described in any one of claims 1-8.

Images