A method for reducing conflicts in a high concurrency scenario of a database intelligent large object

Abstract

This invention discloses a method for reducing conflicts in high-concurrency scenarios involving intelligent large objects in databases. The method includes: in a first transaction, in response to a query request, acquiring a first row lock on the table row, reading the first intelligent large object descriptor and recording the table row position information, and immediately releasing the first row lock; before preparing to read the actual data of the intelligent large object, acquiring a second row lock on the same table row, relocating the table row based on the recorded position information, and reading the second intelligent large object descriptor; reading the actual data of the intelligent large object based on the latest second intelligent large object descriptor, and releasing the second row lock upon completion. This invention, by performing a second locking and rereading the descriptor at a critical moment before reading the actual data, ensures the real-time nature and validity of the data pointers used, thereby completely avoiding query failures caused by data modification during the lock-free window period, and significantly improving the stability and data consistency of the database in high-concurrency scenarios.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a method for reducing conflicts in high-concurrency scenarios involving large intelligent objects in databases. Background Technology

[0002] Database intelligent large object (LOB) technologies, such as text large objects (CLOB) and binary large objects (BLOB), are designed for efficient storage and manipulation of large volumes of unstructured data. Their storage mechanism typically separates the actual data from the main table rows, with each main table row storing only an intelligent large object descriptor pointing to the actual data.

[0003] In traditional smart large object operations, such as query (SELECT) operations, the database system typically executes the operation in two steps: First, it locks the table row, reads the smart large object descriptor within the row, and then immediately releases the row lock; second, it accesses the dedicated smart large object storage area based on the read descriptor to obtain the actual data.

[0004] This two-step separation mechanism with lock release in between has serious flaws. In a high-concurrency environment, when a transaction (e.g., transaction 1) completes the first step but the row lock is released before executing the second step, another concurrent transaction (e.g., transaction 2) can successfully acquire the lock on that row and perform an update or delete operation. This will result in transaction 2 modifying or deleting the smart large object data. Subsequently, when transaction 1 continues to execute the second step, it still uses the descriptor it initially read, which is now outdated, to access the data. This will cause the query to fail or read dirty data because the data has been modified or does not exist, leading to conflicts and errors. Summary of the Invention

[0005] The purpose of this section is to outline some aspects of embodiments of the present invention and to briefly describe some preferred embodiments. Simplifications or omissions may be made in this section, as well as in the abstract and title of this application, to avoid obscuring the purpose of these documents; however, such simplifications or omissions should not be construed as limiting the scope of the invention.

[0006] In view of the aforementioned existing problems, this invention is proposed. Therefore, this invention provides a method for reducing conflicts in high-concurrency scenarios involving large intelligent objects in databases, aiming to solve the concurrency conflict problem caused by the step-by-step execution of query operations without intermediate lock protection.

[0007] To address the aforementioned technical problems, this invention provides the following technical solution: a method for reducing conflicts in high-concurrency scenarios involving large intelligent objects in a database, comprising:

[0008] In the first transaction, in response to a query request for a table row containing a smart large object, the first row lock for that table row is acquired;

[0009] After acquiring the first row lock, read the first smart large object descriptor from the table row, record the position information of the table row, and release the first row lock;

[0010] Before reading the actual data of the smart large object according to the first smart large object descriptor, acquire the second row lock of the table row;

[0011] After acquiring the second row lock, relocation is performed based on the recorded table row position information, and the second smart large object descriptor is read from the table row;

[0012] Based on the second intelligent large object descriptor, read the actual data of the intelligent large object;

[0013] After completing the reading of the actual data of the intelligent large object, release the second row lock.

[0014] As a preferred embodiment of the method for reducing conflicts in high-concurrency scenarios of intelligent large objects in databases as described in this invention, the method of recording the position information of the table row includes: a row identifier that uniquely identifies the table row, and the offset position of the intelligent large object descriptor within the table row.

[0015] As a preferred embodiment of the method for reducing conflicts in high-concurrency scenarios of intelligent large objects in databases as described in this invention, the query request is a query operation targeting one or more columns in a database table that are defined as intelligent large object data types.

[0016] As a preferred embodiment of the method for reducing conflicts in high-concurrency scenarios of intelligent large objects in the database as described in this invention, the intelligent large object data type is a text large object or a binary large object.

[0017] As a preferred embodiment of the method for reducing conflicts in high-concurrency scenarios of intelligent large objects in the database described in this invention, wherein: within the time window after releasing the first row lock and before acquiring the second row lock, a second transaction is allowed to perform update or delete operations on the table row, and the content of the second intelligent large object descriptor is different from the content of the first intelligent large object descriptor.

[0018] As a preferred embodiment of the method for reducing conflicts in high-concurrency scenarios of large intelligent objects in databases as described in this invention, the first transaction and the second transaction are different transactions executed concurrently.

[0019] As a preferred embodiment of the method for reducing conflicts in high-concurrency scenarios of intelligent large objects in databases according to the present invention, wherein: the write operation performed by the second transaction is an update operation or a delete operation; the update operation includes modifying the intelligent large object descriptor in the table row.

[0020] As a preferred embodiment of the method for reducing conflicts in high-concurrency scenarios of large intelligent objects in databases as described in this invention, the first row lock and the second row lock are exclusive locks or update locks that prevent other transactions from performing write operations on the table rows.

[0021] As a preferred embodiment of the method for reducing conflicts in high-concurrency scenarios of intelligent large objects in the database as described in this invention, if it is found that the table row has been deleted when relocating based on the table row position information of the record, the subsequent step of reading the second intelligent large object descriptor is stopped.

[0022] As a preferred embodiment of the method for reducing conflicts in high-concurrency scenarios of intelligent large objects in the database as described in this invention, the method further includes: reading the actual data of the intelligent large object according to the second intelligent large object descriptor;

[0023] Before reading the actual data of the smart large object according to the second smart large object descriptor, acquire the object lock of the smart large object, and release the object lock of the smart large object after completing the reading of the actual data of the smart large object.

[0024] Compared with the prior art, the beneficial effects of the invention are as follows: By performing secondary locking on the table row and rereading the intelligent large object descriptor before reading the intelligent large object data, the invention ensures that the descriptor used to locate the final data is the latest and valid, thereby guaranteeing data consistency; even if other transactions modify the data of the row during the interval between the two locking operations, this method can still obtain the latest data pointer, thereby avoiding query errors. Attached Figure Description

[0025] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein:

[0026] Figure 1 This is a flowchart illustrating the overall process of a method for reducing conflicts in high-concurrency scenarios involving large intelligent objects in a database, as described in one embodiment of the present invention.

[0027] Figure 2This is a sequence diagram of multiple transactions of intelligent large objects in the prior art, which is a method for reducing conflicts in high-concurrency scenarios of intelligent large objects in a database according to an embodiment of the present invention.

[0028] Figure 3 This is a sequence diagram of multiple transactions of intelligent large objects in the present invention, which is a method for reducing conflicts in high-concurrency scenarios of intelligent large objects in databases according to an embodiment of the present invention.

[0029] Figure 4 The figure shows the test results of the prior art solution of the method for reducing conflicts in high-concurrency scenarios of large intelligent objects in databases, as described in an embodiment of the present invention.

[0030] Figure 5 The figure shows the test results of the method for reducing conflicts in high-concurrency scenarios of large intelligent objects in databases, as described in one embodiment of the present invention. Detailed Implementation

[0031] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of the present invention.

[0032] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0033] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0034] This invention is described in detail with reference to the schematic diagrams. When detailing the embodiments of this invention, for ease of explanation, the cross-sectional views illustrating the device structure may be partially enlarged, not adhering to the usual scale. Furthermore, the schematic diagrams are merely examples and should not be construed as limiting the scope of protection of this invention. In actual fabrication, the three-dimensional spatial dimensions of length, width, and depth should be included.

[0035] Furthermore, in the description of this invention, it should be noted that the terms "upper," "lower," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. These terms are used solely for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. In addition, the terms "first," "second," or "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0036] Unless otherwise explicitly specified and limited, the terms "installation," "connection," and "joining" in this invention should be interpreted broadly. For example, they can refer to fixed connections, detachable connections, or integral connections; similarly, they can refer to mechanical connections, electrical connections, or direct connections, or indirect connections through an intermediate medium, or internal connections between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0037] Example 1

[0038] Reference Figure 1 This is the first embodiment of the present invention, which provides a method for reducing conflicts in high-concurrency scenarios involving large intelligent objects in a database, including:

[0039] S1. In the first transaction, respond to the query request for the table row containing the smart large object and acquire the first row lock of the table row;

[0040] It should be noted that the first transaction refers to an atomic unit of work initiated within a database session to perform one or more logically related operations. In the scenario of this invention, the purpose of this transaction is to query and read a smart large object from the database. That is, in a typical concurrent environment, it means that at the same time, there may be multiple other transactions attempting to access or modify the same data in the database.

[0041] It should be noted that responding to a query request for a table row containing Smart Large Objects refers to the specific database operation performed by the first transaction. This query request is typically an SQL SELECT statement whose query target explicitly points to one or more columns defined as Smart Large Object data types (i.e., Text Large Object (CLOB) or Binary Large Object (BLOB)). For example, a typical query request could be SELECT photo_blob FROM employee_table WHERE employee_id=101, where the row in employee_table where employee_id is 101 is the table row containing Smart Large Objects, and the photo_blob column is the Smart Large Object column.

[0042] Furthermore, once the database system locates the specific table row pointed to by the query request, the first transaction will not read the data immediately, but will first apply a row-level lock to that row, which is the first row lock;

[0043] It should be noted that the purpose of acquiring this first row lock is to ensure the atomicity and consistency of the upcoming first smart large object descriptor read operation. This ensures that no other concurrent transaction can modify or delete this row at the moment the first transaction reads the descriptor, thereby preventing the reading of intermediate states or inconsistent data caused by concurrent modifications. Since the granularity of this lock is controlled at the row level, locking the entire data page or table is avoided.

[0044] S2. After acquiring the first row lock, read the first smart large object descriptor from the table row, record the position information of the table row, and release the first row lock;

[0045] Furthermore, under the protection of the first row lock acquired in the first transaction, the operation of reading the first smart large object descriptor from the table row is performed;

[0046] It should be noted that the first intelligent large object descriptor is a small data structure (72-byte structure) stored inside the table row data. It does not contain intelligent large object data itself, but serves as a pointer to the actual data in external storage or a metadata handle. The purpose of reading this descriptor is to obtain the basic information needed to access the actual data. Furthermore, due to the presence of row locks at this time, it can be guaranteed that the descriptor read is complete and has not been concurrently modified.

[0047] Furthermore, after reading the descriptor, the operation of recording the position information of the table row is performed. This position information includes two parts:

[0048] The first part is the row identifier that uniquely identifies the table row. This row identifier is the address used internally by the database to uniquely identify the physical or logical location of a row. By recording this row identifier, the database system can directly and quickly access the data in the row without index scan or full table scan in subsequent steps, which greatly improves the efficiency of relocation.

[0049] The second part is the offset position of the Smart Large Object Descriptor within the table row. Since a row of data usually consists of multiple columns, this offset position records the starting byte position of the Smart Large Object Descriptor in the data structure of this row. By combining the row identifier and the offset position, a coordinate can be formed. Based on this coordinate position, it can be ensured that subsequent reread operations can accurately hit the same descriptor field.

[0050] It should be noted that the first transaction will store this location information in its internal working memory;

[0051] Furthermore, after completing the above read and record operations, the first transaction will immediately execute the operation of releasing the lock on the first row;

[0052] It should be noted that the purpose of releasing the lock is to maximize the concurrency performance of the database. By shortening the holding time of the row lock to only cover the tiny time segment of reading the descriptor and record position, the table row can be quickly accessed by other concurrent transactions, allowing them to perform update or delete operations.

[0053] S3. Before reading the actual data of the smart large object based on the first smart large object descriptor, acquire the second row lock of the table row;

[0054] Furthermore, since the first transaction has already released the lock on the first row, there will be a time window between the release of the lock and the execution of this step. This time window is an unprotected time window. During this time window, the first transaction may be performing other computational tasks or preparing network, memory, and other resources to receive the smart large object data. By allowing one or more second transactions to perform update or delete operations on the table rows and making the content of the second smart large object descriptor different from the content of the first smart large object descriptor, a typical conflict scenario is formed.

[0055] Specifically, the first transaction and the second transaction are different transactions executed concurrently;

[0056] Furthermore, the first transaction sends another lock request to the database's lock manager for the same table row; this lock is the second row lock.

[0057] Specifically, the first transaction uses the location information recorded in its internal working memory to specify the target row to be locked to the lock manager;

[0058] In addition, the second row lock is of the same type as the first row lock, both of which are locks that prevent other transactions from writing to the table rows, and are either exclusive locks or update locks;

[0059] It should be noted that by applying this type of lock, it is ensured that from this moment until the second row lock is released, the contents of this table row (including its internal smart large object descriptor) will not be modified by any other concurrent transactions.

[0060] S4. After acquiring the second row lock, relocate based on the recorded table row position information and read the second smart large object descriptor from the table row.

[0061] Specifically, during the relocation process, there are two possible scenarios:

[0062] In the first scenario, relocation is successful, and the database system successfully locates the table row based on its row identifier. This is the most common scenario, indicating that the row was not deleted during the interval between the two locking events.

[0063] In the second scenario, relocation fails because the database system cannot find the table row based on its row identifier. This indicates that after releasing the first row lock and before acquiring the second row lock, another concurrent transaction (i.e., the second transaction) performed a delete operation, physically or logically deleting the row. When this situation is detected, the system can abort the subsequent steps of reading the second smart object descriptor and return an error indicating that the table row does not exist to the upper-level application to avoid invalid subsequent operations.

[0064] Furthermore, after successfully relocating to the table row, the operation of reading the second smart large object descriptor from the table row is then performed; the second smart large object descriptor refers to the descriptor content stored at the offset position of the table row at the current time; since the first transaction holds the second row lock at this time, it can be ensured that the descriptor read is the latest and transaction-consistent state.

[0065] It should be noted that the content of the second intelligent large object descriptor may be the same as the first intelligent large object descriptor read (if no concurrent write operation occurs), or it may be different (if a second transaction has updated the row); however, the solution of this invention does not care whether the two descriptors are the same, but unconditionally trusts and uses this newly acquired second intelligent large object descriptor.

[0066] It should be noted that by relocation and rereading under lock protection, the final confirmation of the table row status is completed. This not only handles the abnormal situation that the table row may be deleted, but also obtains a currently absolutely valid "pointer" for accessing the actual data, thereby solving the fundamental problem of concurrency conflicts caused by the use of deprecated descriptors.

[0067] S5. Read the actual data of the intelligent large object based on the second intelligent large object descriptor;

[0068] Furthermore, the specific process of reading the actual data of the intelligent large object is as follows:

[0069] The database's intelligent large object manager first parses the second intelligent large object descriptor, which contains all the metadata needed to locate and access the actual data, such as the identifier of the dedicated storage space where the data resides, the address of the starting data page, the total length of the object, and storage attributes. Before accessing the physical storage based on the parsed metadata, the first transaction executes a crucial sub-step:

[0070] Acquire an object lock for the smart large object. This object lock is a different type of lock from row locks. It represents the data of the smart large object itself, rather than the table row storing the descriptor. The purpose of this lock is to prevent other transactions (e.g., a transaction performing an update that may have already passed the row lock phase and is waiting for data in the operation special page) from modifying (such as appending, truncating, or replacing) the actual content of the smart large object while the first transaction is reading the smart large object's data.

[0071] It should be noted that by applying an object lock, the content of the data is kept static during the first transaction's data reading, thus ensuring the integrity and consistency of the read data.

[0072] After successfully acquiring the object lock, the Smart Large Object Manager uses the metadata parsed from the descriptor to access the dedicated page storing the Smart Large Object data. Since the Smart Large Object is very large, its data may span multiple non-contiguous data pages. The manager will read all relevant data pages sequentially or concurrently according to the internal link or index structure, and collect and organize the data blocks, and then stream them to the working memory or client buffer of the first transaction that initiated the query.

[0073] After the first transaction completes reading the actual data of the smart object, the object lock of the smart object is released immediately, minimizing the locking time of the smart object data. Once the reading is complete, other waiting transactions are allowed to operate on it, thus balancing data consistency and system concurrency.

[0074] It should be noted that, after the above process, the first transaction can obtain intelligent large object data that is completely consistent with the current database state, ensuring that the data read is the correct data after being updated or not modified, thereby avoiding query failures or data inconsistencies caused by using outdated descriptors.

[0075] S6. After completing the reading of the actual data of the intelligent large object, release the second row lock;

[0076] Furthermore, the row lock release operation is only triggered after all data (regardless of its size) has been successfully read from the dedicated storage page and transferred to the first transaction; this ensures that the table row's metadata (i.e., the intelligent large object descriptor) remains stable and protected throughout the entire data reading process, preventing potential problems caused by rows being modified or deleted by other transactions while the data is being read.

[0077] Furthermore, once the second row lock is released, the table row immediately becomes available to all other concurrent transactions, allowing for new queries, updates, or deletions. This minimizes the blocking time caused to other business processes by querying a large object, ensuring high throughput for the entire database system.

[0078] It should be noted that the consequence of releasing the lock is that the write protection of the first transaction on that row of the table ends; that is, from this moment on, the first transaction no longer prevents other transactions from modifying that row, but this will not affect the results already obtained by the first transaction.

[0079] Example 2

[0080] Reference Figure 2 and Figure 3 This is the second embodiment of the present invention, which provides a method for reducing conflicts in high-concurrency scenarios involving large intelligent objects in a database, including:

[0081] refer to Figure 2 The existing technical solution processes are as follows:

[0082] The T1 transaction executes a query for smart large objects at time t1, first reading the 72-byte smart large object descriptor from the table row, and then releasing the lock on the table row;

[0083] The T2 transaction executes a delete or update statement at time t2, and the data in that row is modified.

[0084] Transaction T1 reads the smart large object data based on the 72-byte smart large object descriptor retrieved at time t3. Since the smart large object data was modified by transaction T2 at time t2, transaction T1's query results in an error.

[0085] refer to Figure 3 The processing procedure of the present invention is as follows:

[0086] Transaction T1 executes a query for a large smart object at time t1, locking the table rows;

[0087] Read the 72-byte Smart Large Object descriptor from the table row and record table-related information, Smart Large Object offset, etc., and store them in the 72-byte descriptor;

[0088] Unlock the table row;

[0089] The T2 transaction executes a delete or update statement at time t2, and the data in that row is modified.

[0090] T1 transaction locks the table rows;

[0091] Before querying the actual data of the smart large object at time t3, transaction T1 rereads the new 72-byte smart large object descriptor of the table row based on the table-related information recorded above;

[0092] Locking large smart objects;

[0093] At time t4, transaction T1 queries the smart large object data based on the new 72-byte smart large object descriptor;

[0094] Unlock smart large objects;

[0095] Unlock the table row;

[0096] It should be noted that existing technologies involve two steps in querying intelligent large objects: first, querying the 72-byte intelligent large object descriptor from the table row, and then querying the intelligent large object data based on the retrieved 72-byte intelligent large object descriptor. In contrast, this invention first queries the 72-byte intelligent large object descriptor from the table row, then queries the intelligent large object data using the 72-byte intelligent large object descriptor. After obtaining the 72-byte intelligent large object descriptor, instead of querying the intelligent large object data immediately, it uses the table-related information in the 72-byte intelligent large object descriptor to query the 72-byte intelligent large object descriptor again from the table row, while simultaneously locking the table row. The newly retrieved 72-byte intelligent large object descriptor is then used to query the intelligent large object data. After the query is complete, the table row is unlocked to prevent the data in that row from being tampered with during the intelligent large object data query, thus solving the problems of conflicts and query errors in high-concurrency scenarios involving intelligent large objects.

[0097] Example 3

[0098] Reference Figure 4 and Figure 5 This is the third embodiment of the present invention, which provides a method for reducing conflicts in high-concurrency scenarios involving large intelligent objects in a database, including:

[0099] Using JMeter to perform load testing on update and query statements with a concurrency of 40 for 10 minutes, it was found that queries no longer threw errors and update errors were greatly reduced.

[0100] from Figure 4 It can be seen that the existing solution has a query error rate of 55.74% and an update error rate of 4.89%; from Figure 5 It can be seen that the error rate for querying our invention solution is 0%, and the error rate for updating is 1.14%.

[0101] Compared with existing technical solutions, the query error rate is reduced from 55.74% to 0%, and the update error rate is reduced to 1.14%; the improvement is significant, proving that the solution of the present invention can reduce conflicts in high-concurrency scenarios.

[0102] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The solutions in the embodiments of this application can be implemented using various computer languages, such as the object-oriented programming language Java and the interpreted scripting language JavaScript.

[0103] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0104] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0105] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0106] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0107] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for reducing conflicts in high-concurrency scenarios involving large intelligent objects in a database, characterized in that, include: In the first transaction, in response to a query request for a table row containing a smart large object, the first row lock for that table row is acquired; After acquiring the first row lock, read the first smart large object descriptor from the table row, record the position information of the table row, and release the first row lock; Before reading the actual data of the smart large object according to the first smart large object descriptor, acquire the second row lock of the table row; Within the time window between releasing the first row lock and acquiring the second row lock, the second transaction is allowed to perform update or delete operations on the table row, and the content of the second smart large object descriptor is different from the content of the first smart large object descriptor. After acquiring the second row lock, relocation is performed based on the recorded table row position information, and the second smart large object descriptor is read from the table row; Based on the second intelligent large object descriptor, read the actual data of the intelligent large object; After completing the reading of the actual data of the intelligent large object, release the second row lock.

2. The method for reducing conflicts in high-concurrency scenarios involving large intelligent objects in a database as described in claim 1, characterized in that, The recorded position information of the table row includes: a row identifier that uniquely identifies the table row, and the offset position of the smart large object descriptor within the table row.

3. The method for reducing conflicts in high-concurrency scenarios involving large intelligent objects in a database, as described in claim 1, is characterized in that... The query request is a query operation targeting one or more columns in a database table that are defined as smart large object data types.

4. The method for reducing conflicts in high-concurrency scenarios involving large intelligent objects in a database, as described in claim 3, is characterized in that... The data type of the intelligent large object is either a text large object or a binary large object.

5. The method for reducing conflicts in high-concurrency scenarios involving large intelligent objects in a database as described in claim 1, characterized in that, The first transaction and the second transaction are different transactions executed concurrently.

6. The method for reducing conflicts in high-concurrency scenarios involving large intelligent objects in a database, as described in claim 1, is characterized in that... The write operation performed by the second transaction is either an update operation or a delete operation; the update operation includes modifying the smart large object descriptor in the table row.

7. The method for reducing conflicts in high-concurrency scenarios involving large intelligent objects in a database, as described in claim 1, is characterized in that... The first row lock and the second row lock are exclusive locks or update locks that prevent other transactions from writing to the table rows.

8. The method for reducing conflicts in high-concurrency scenarios involving large intelligent objects in a database as described in claim 1, characterized in that, If, during relocation based on the recorded table row location information, it is found that the table row has been deleted, the subsequent steps of reading the second intelligent large object descriptor are aborted.

9. The method for reducing conflicts in high-concurrency scenarios involving large intelligent objects in a database as described in claim 1, characterized in that, Reading the actual data of the smart large object according to the second smart large object descriptor further includes: acquiring the object lock of the smart large object before reading the actual data of the smart large object according to the second smart large object descriptor, and releasing the object lock of the smart large object after completing the reading of the actual data of the smart large object.

Images