An Embedded Database Transaction Concurrency Control Method Based on Tianmai Operating System

Abstract

The application discloses a kind of embedded database transaction concurrency control methods based on Tianmai operating system, the core problem solved is in the limited resource environment faced by Tianmai operating system, how to effectively utilize system resources on the basis of ensuring data consistency, reliability and security, improve system concurrency, so as to guarantee the sustained and stable operation of system.Through the design of the application, the needs of database transaction concurrency control in avionics system based on Tianmai operating system can be effectively met, and the strict requirements of new generation avionics system are adapted.

Description

Technical Field

[0001] This invention belongs to the field of database technology, specifically relating to an embedded database transaction concurrency control method based on the Tianmai operating system. Background Technology

[0002] Tianmai Operating System is a partition-based, highly secure, and reliable embedded multi-core real-time operating system specifically developed for next-generation avionics systems. It supports integrated avionics systems and is currently widely used in various avionics systems. The emergence of this operating system has brought higher security and reliability to avionics systems, while also posing new challenges to data processing.

[0003] In traditional avionics systems, due to the relatively small amount of data processed, applications typically have their own independent data, and the need for data sharing between applications is minimal. Even when some data needs to be shared across multiple applications, data redundancy is usually employed, meaning that identical data has independent backups in each application. However, with the rapid development of various sensor technologies, the complexity of avionics systems is constantly increasing, and the amount of data collected by aircraft during flight is exploding. This increase in data volume means that traditional data processing methods can no longer meet the demands for efficient data access and processing.

[0004] Therefore, to address these challenges, avionics systems urgently need to incorporate dedicated databases or data management modules to support efficient management of explosive data growth. These databases or data management modules must not only adapt to the specific needs of avionics systems, such as high security, real-time performance, and embeddedness, but also effectively handle concurrent access, ensuring data consistency and system stability.

[0005] Currently, mainstream embedded databases on the market, such as SQLite, BerkeleyDB, and Empress, while performing excellently in general scenarios, face a series of problems and challenges in the aviation field, especially in safety-critical areas. Take SQLite as an example: this widely used SQL embedded database is known for its speed, simplicity, small size, and reliability. However, in environments like avionics systems, where real-time performance and complexity are extremely demanding, SQLite's capabilities in transaction concurrency control are limited. In particular, its database-level locking mechanism, while advantageous in simplifying management, has a coarse granularity, which limits its concurrent processing capabilities in high-concurrency and high-real-time avionics system applications. Therefore, in these scenarios, SQLite struggles to meet the stringent requirements of high concurrency and real-time performance in avionics systems. Similarly, while BerkeleyDB and Empress excel in performance and reliability, their shortcomings in embeddability, real-time capabilities, and customizability make them difficult to fully adapt to the specific needs of the aviation field.

[0006] With the rapid growth of data volume and the increasing importance of data privacy, higher demands are being placed on database management systems. Especially in the field of massive data management, while existing domestic database management systems have made progress in concurrency, throughput, and scalability, they often lack the embeddedness, real-time performance, availability, and customizability required for the aviation industry. These database management systems cannot be simply tailored to meet the stringent transaction concurrency control requirements of avionics systems.

[0007] Under the Tianmai operating system, the database management system faces a series of unique challenges. First, the Tianmai operating system places specific requirements on the database management system, including high security, real-time performance, and embeddedness. Second, existing technologies have significant limitations in adapting to the Tianmai operating system, especially in transaction concurrency control. Finally, the importance of a database transaction concurrency control scheme in avionics systems cannot be ignored, as it directly relates to the concurrency, reliability, and security of the database system, as well as its overall database performance and robustness.

[0008] To meet the needs of multiple applications in next-generation avionics systems accessing the same data through a unified interface provided by the database, while ensuring data consistency and security, the airborne embedded database must implement concurrent and secure handling of multiple data access requests. Therefore, transaction concurrency control technology in the database management system is crucial. The design principles, processing strategies, and implementation algorithms of transaction concurrency control are key to ensuring the stable operation of the database system in a high-concurrency environment. Summary of the Invention

[0009] To overcome the shortcomings of existing technologies, this invention provides an embedded database transaction concurrency control method based on the Tianmai operating system. The core problem addressed is how to effectively utilize system resources and improve system concurrency while ensuring data consistency, reliability, and security in the resource-constrained environment of the Tianmai operating system, thereby guaranteeing the continuous and stable operation of the system. Through the design of this invention, the requirements for database transaction concurrency control in avionics systems based on the Tianmai operating system can be effectively met, adapting to the stringent requirements of next-generation avionics systems.

[0010] The technical solution adopted by this invention to solve its technical problem is as follows:

[0011] Step 1: Construct system locks and transaction locks;

[0012] In the airborne database, the database files are organized in units of pages, with B+ trees as the underlying data structure. System locks are used to protect the physical structure of the B+ tree under multi-threading, and transaction locks of the lock manager are used to implement locking operations on data records.

[0013] Step 1-1: System lock;

[0014] A system lock based on semaphores allows multiple threads to read shared resources simultaneously, but only one thread is allowed to perform a write operation at any given time.

[0015] Steps 1-2: Transaction locks;

[0016] By employing two types of locks—read locks (shared locks) and write locks (exclusive locks)—concurrent operations are categorized into four types: read-read, read-write, write-read, and write-write. At least concurrent read-read operations are allowed, resulting in the lock compatibility matrix.

[0017] Concurrent operations are only allowed when different transactions all have read locks on the same data item; otherwise, new lock requests cannot be granted. When the same transaction acquires a lock on the same data item, lock escalation may occur.

[0018] A page-level locking mechanism is adopted to achieve transaction concurrency control by locking on pages;

[0019] Step 2: Selecting a transaction concurrency control protocol;

[0020] A pessimistic concurrency control protocol is adopted, meaning that all exclusive locks held by a transaction can only be released after the transaction is committed; any data written by an uncommitted transaction is locked with an exclusive lock before the uncommitted transaction is committed, preventing other transactions from reading this data; therefore, in the GROWING phase, a transaction can acquire both read locks and write locks, but can only release read locks; in the SHRINKING phase, a transaction can only acquire read locks, not write locks, and all write locks can only be released after the transaction is committed or aborted.

[0021] Step 3: Select the transaction isolation level;

[0022] There are four transaction isolation levels: Read Uncommitted, Read Committed, Repeatable Read, and Serializable.

[0023] The Read Committed isolation scheme allows transactions to read modifications made by other committed transactions; however, during the execution of a transaction, the current transaction is not allowed to read modifications being made by other transactions.

[0024] Under the Read Committed isolation level, a transaction can only see the latest data state that has been committed by other transactions when reading data;

[0025] Step 4: Transaction rollback mechanism;

[0026] When a transaction modifies a data page, it not only updates the actual data page, but also saves the old page before the transaction's modification in memory as a shadow page of the newly modified dirty page, which is maintained using the OldPage hash table.

[0027] Shadow pages are stored in memory, not on disk. When a conflict occurs between different transactions and a transaction needs to be rolled back, since all the pages that the transaction has modified are locked by the lock manager's transaction locks, the previously saved shadow pages can be used to overwrite the current data pages, so that the data returns to the consistent state before the modification.

[0028] Preferably, the system lock is as follows:

[0029] A counter variable is used to track the number of readers who have successfully acquired a read lock. During the read lock acquisition process, only the first reader who requests the read lock will actually acquire the lock, while other subsequent readers will only increment the counter and mark the current lock state as "read mode". When a write lock is requested, the system will directly call the interface to acquire the write lock, and after successful acquisition, the current lock state will be set to "write mode". During the lock release process, if it is a read lock, the actual lock release operation is performed by the last reader to leave; if it is a write lock, the write lock will be released immediately after the write operation is completed.

[0030] The allocation and release of system lock resources are centrally managed through an independent lock pool. During database system initialization, the system automatically initializes the lock pool and dynamically calculates its capacity based on the size of the cache pool. This method ensures efficient allocation and reclamation of lock pool resources while avoiding the performance overhead caused by frequent lock creation and destruction.

[0031] Preferably, the transaction lock is as follows:

[0032] A lock manager is designed to centrally and uniformly manage transaction locks. Under the premise of page-level locking, the lock manager maintains a lock table for each page that needs to be accessed, and stores it in memory using a HashMap according to the mapping relationship between page number and lock table. The lock table stores the current lock status of the page and the information of different transactions requesting locks on the page, specifically including four parts: group mode, wait bit, number of transactions granted the current lock, and list.

[0033] ① When a transaction requests a lock on page A, the lock request is not compared one by one with the locks held by other transactions on that page. Instead, the grant / deny decision is simplified by comparing only the request with the group schema. The specific rules are as follows:

[0034] aS indicates that only read locks are held, and there may be multiple read locks.

[0035] bX indicates that there is only one write lock and no other locks;

[0036] ② The wait bit indicates that at least one transaction is waiting for a lock on page A;

[0037] ③ The number of transactions that have been granted the current lock; records how many transactions have been granted the current lock in the current group mode;

[0038] ④ A list describing all transactions that either currently hold a lock on page A or are waiting for a lock on page A; useful information in each list item includes:

[0039] a. The transaction ID that holds the lock or is waiting for the lock;

[0040] b. The type of lock requested in the transaction;

[0041] c. Whether the transaction holds the lock or waits for the lock;

[0042] All these list items on page A are stored in an array ArrayList;

[0043] 1) Lock application;

[0044] Suppose transaction T requests a lock on page A. The handling of lock requests between different transactions can be categorized into the following scenarios:

[0045] ①If there is no lock entry for page A, then there is definitely no lock on page A, so the corresponding entry is created and the request is granted;

[0046] ② If a lock table entry for page A exists, then the group schema is found. According to the grant / deny rules of the group schema, if a read lock already exists on page A, another read lock can be granted. In this case, transaction T's entry in the list will have "wait=No", while the write lock will be denied, and an entry indicating that transaction T requested the lock will be added to the list with "wait=Yes". If a write lock already exists on page A, then no other lock can be granted, and transaction T's entry in the list will have "wait=Yes".

[0047] The above describes the handling of lock requests between different transactions. For the same transaction T, if it has already acquired a read lock on page A, it needs to upgrade the lock. If the current lock table group mode is read lock and there is only one read lock, then a write lock can be granted to transaction T directly. The locking mode of transaction T's item in the list will be changed to write lock, and the group mode needs to be changed to write lock. Otherwise, it will not be granted. The locking mode of transaction T's item in the list will be changed to write lock, and the wait bit will also be changed to "wait=Yes".

[0048] 2) Releasing the lock;

[0049] Suppose transaction T unlocks page A. The entry for transaction T regarding page A in the list will be deleted. If other entries still exist in the list, a new group pattern needs to be found according to the first-come, first-served principle. If the new group pattern is a write lock, there will be no other locks. However, if it is a read lock, it is necessary to determine whether there are any other read locks.

[0050] 3) Deadlock detection;

[0051] A timeout mechanism is used to resolve deadlock issues.

[0052] Preferably, the pessimistic concurrency control protocol is a strict two-phase locking protocol, as follows:

[0053] During the lock growth phase, read locks or write locks can be acquired. Read locks can be released immediately after use, while write locks must be held until the transaction is committed. During transaction execution, read locks are released immediately to reduce lock holding time, while write locks must be released uniformly after the transaction is committed to ensure data consistency.

[0054] The strict two-phase locking protocol is explained for the four operations of querying, inserting, deleting and updating the primary index B+ tree;

[0055] (1) Query operation;

[0056] ① Read operations start from the root node, first acquiring the system read lock on the root node, and then acquiring the transaction read lock on the root node;

[0057] ②The read operation first acquires the system read lock of the corresponding child node based on the query conditions, then acquires the transaction read lock, and then releases the parent node's transaction read lock and system read lock;

[0058] ③ Repeat the execution process of step ② until a leaf node that meets the conditions is found; however, in the leaf node, a transaction read lock needs to be acquired first and then a system read lock is acquired. The deadlock detection mechanism of the transaction lock manager is used to detect and resolve the deadlock.

[0059] ④ After reading the contents of the leaf node, release the system read lock and transaction read lock on the leaf node;

[0060] When a transaction performs a read operation, the system read lock is used to protect the physical structure of the B+ tree, while the transaction read lock is used to protect the data records. Both the system read lock and the transaction read lock are released immediately after use and do not need to be held until the transaction commit phase.

[0061] (2) Insert / delete operations;

[0062] ① When locking a B+ tree during a write operation, an optimistic strategy is first used to set the lock to the query state;

[0063] ② Upon reaching a leaf node, first acquire a transaction read lock to determine if the node is safe, i.e., whether the operation will cause the node to split / merge or otherwise modify the tree structure. If the node is safe, upgrade the transaction read lock to a transaction write lock, and then acquire a system write lock, thus completing the locking process. If the node is not safe, release all locks and continue with the subsequent steps, using a pessimistic strategy to start locking again from the root node.

[0064] ③ Under the pessimistic strategy, the write operation also starts from the root node, first holding the system write lock of the root node, and adding the locked node to the transaction's write lock node set;

[0065] ④ The write operation first acquires the system write lock on the child node, and then determines whether the child node is a safe node. If the child node is a safe node, the write operation immediately releases the system write lock on the ancestor node; otherwise, it temporarily holds the system write lock on the parent node and adds the node to the transaction's write lock node set. This process is repeated until a leaf node is found.

[0066] ⑤ Once a leaf node is reached, a transaction write lock must be acquired first, followed by a system write lock;

[0067] ⑥ Since the transaction write lock was not acquired at the same time as the system write lock on the non-leaf node, it is necessary to acquire the transaction write lock separately on all locked non-leaf nodes.

[0068] ⑦ After a write operation modifies the content of this branch, it releases the system write lock for that branch. Transaction write locks are not released until the transaction is committed or rolled back.

[0069] (3) Update operation;

[0070] The update operation adopts the in-place update method, that is, the data is modified without changing the B+ tree structure. In the update operation, it is first necessary to acquire the transaction write lock and system write lock of the leaf node. After the operation is completed, the system write lock will be released immediately, while the transaction write lock will not be released until the transaction is committed.

[0071] Preferably, the implementation of the read-committed isolation level is as follows:

[0072] In the implementation of the Read Committed isolation level, transaction read locks are released immediately after use; when a transaction reads the same record again, it needs to reacquire the transaction read lock; while transaction write locks are held until the transaction is committed or rolled back. The process will be described through the four operations of query, insert, delete and update of the primary index B+ tree.

[0073] (1) Query operation;

[0074] According to the read committed isolation level, transaction read locks are released immediately after use; in onboard database systems, using transaction read locks to lock nodes effectively prevents reading uncommitted content.

[0075] (2) Insert / delete operations;

[0076] According to the requirements of the Read Committed isolation level, the write lock of a transaction will remain locked until the transaction is committed, ensuring that other transactions cannot read the uncommitted content;

[0077] (3) Update operation;

[0078] When reading internal nodes of a B+ tree, a transaction read lock is first acquired, and then the lock is released immediately after the read operation is completed. For leaf nodes that are being updated, a transaction write lock is continuously used to lock them until the transaction is committed.

[0079] Preferably, step 4 specifically comprises:

[0080] After a transaction deadlock occurs, the transaction lock manager triggers the deadlock detection mechanism and immediately rolls back the transaction that failed to acquire the lock. To ensure the atomicity and consistency of transactions, when any page is modified during the execution of a transaction, the page is backed up to the old page set. When a transaction needs to be rolled back, all modified pages are locked by the transaction write lock. All page sets locked by the transaction are accessed one by one, and the corresponding page is retrieved from the old page set according to the page ID to restore the currently modified page and restore it to the state before the transaction was executed.

[0081] A computer program that causes a computer to execute the aforementioned embedded database transaction concurrency control method.

[0082] An electronic device includes a processor and a memory; the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory to enable the electronic device to perform the above-described embedded database transaction concurrency control method.

[0083] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described embedded database transaction concurrency control method.

[0084] A chip includes a processor for retrieving and running a computer program from memory, causing a device equipped with the chip to execute the aforementioned embedded database transaction concurrency control method.

[0085] A computer program product includes a computer storage medium storing a computer program, the computer program including instructions executable by at least one processor, which, when executed by the at least one processor, implement the aforementioned embedded database transaction concurrency control method.

[0086] The beneficial effects of this invention are as follows:

[0087] (1) The transaction concurrency control scheme designed in this invention adopts page-level locking. This choice of lock granularity fully considers the constraints of limited resources in the onboard environment and the need to improve transaction concurrency. Compared with larger-granularity table locks or database-level locks, using larger-granularity locks will significantly limit concurrency. While row-level locks can provide higher concurrency, they require maintaining more additional information, increasing the complexity of the system and resource consumption. Therefore, page-level locking, as a compromise, ensures appropriate concurrency while avoiding the excessive overhead of row-level locks, effectively controlling access to database data pages, reducing conflicts between transactions, and thus improving the overall concurrency performance of the system.

[0088] (2) The transaction concurrency control scheme designed in this invention uses a combination of physical locks and logical locks to avoid holding physical locks for a long time during the transaction lifecycle and reduce the overhead of locking operations in transaction concurrency.

[0089] (3) The transaction concurrency control scheme designed in this invention is specifically optimized and customized for the Tianmai operating system, especially in terms of lock management and implementation, which can significantly improve the performance of the database system on the Tianmai operating system. Through lock pool management, the system can reuse lock resources more efficiently, avoiding the high overhead of creating and destroying locks every time a lock is requested, thus improving the efficiency of transaction concurrency control. Attached Figure Description

[0090] Figure 1 The system lock acquisition and unlocking process includes (a) the process of acquiring a write lock / read lock, and (b) the process of releasing a write lock / read lock.

[0091] Figure 2 A sequence diagram for lock pool management;

[0092] Figure 3 This is a structural diagram of the lock table entry;

[0093] Figure 4 This is a diagram illustrating the deadlock phenomenon.

[0094] Figure 5 This is a diagram illustrating the transaction rollback mechanism.

[0095] Figure 6 This is a diagram illustrating the B+ tree query process.

[0096] Figure 7 This is a diagram illustrating the insertion / deletion operation process.

[0097] Figure 8 This is a diagram illustrating the update process.

[0098] Figure 9 This is a diagram illustrating the transaction rollback process. Detailed Implementation

[0099] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0100] To address the limitations of traditional database technologies in airborne system development, such as their large size and long latency, this invention focuses on transaction concurrency control of databases, with in-depth design and implementation specifically for the Tianmai operating system. The Tianmai operating system's specific requirements for the database management system, including high security, real-time performance, and embeddability, make traditional transaction concurrency control schemes insufficient for the needs of avionics systems.

[0101] The core problem this invention aims to solve is how to effectively utilize system resources and improve system concurrency in a resource-constrained environment, while ensuring data consistency, reliability, and security, thereby guaranteeing the continuous and stable operation of the system, within the context of the Tianmai operating system. Through the innovative design of this invention, the requirements for database transaction concurrency control in avionics systems based on the Tianmai operating system can be effectively met, adapting to the stringent requirements of next-generation avionics systems.

[0102] The technical solution adopted by this invention to solve its technical problem includes the following:

[0103] 1. System Locks and Transaction Locks: In onboard databases, database files are organized in pages, using B+ trees as the underlying data structure. Based on this, a clear distinction is made between the physical content (data structure) and logical content (data records) of the B+ tree. Changes to data records pertain to the logical content, while the splitting and merging of nodes pertain to the physical content. A "top-down, left-to-right" crab-like locking protocol is adopted. System locks are used to protect the structural safety of the B+ tree in a multi-threaded environment, while transaction locks from the lock manager are used to lock data records. This ensures that system locks do not need to be held for extended periods, while transaction locks are synchronized with the lifecycle of transactions, reducing locking overhead and thus enabling high concurrency in a multi-threaded environment.

[0104] (1) System lock;

[0105] In the Linux operating system environment, to effectively protect shared resources, the operating system's provided locking mechanisms are typically used, such as the pthread library based on the POSIX interface, for thread synchronization and mutual exclusion. However, since the Tianmai operating system does not support the POSIX interface, it is necessary to design and encapsulate an adapted locking interface to meet the system's specific functional requirements for the locking mechanism.

[0106] Semaphores, as a resource access control mechanism, are widely used in thread synchronization and mutual exclusion scenarios. The ARINC653 standard only defines a counting semaphore type, while the Tianmai ACoreOSMP653 operating system V1.0.6.03, a partitioned operating system, extends the functionality of mutex semaphores on top of APEX semaphores, adding a new mutex semaphore type to support mutual exclusion access to critical resources within a partition. However, the functionality of mutex semaphores is relatively limited, only achieving complete mutual exclusion access to resources, lacking flexibility. Therefore, this research chooses to implement a read-write lock based on semaphores to meet the higher requirements for shared resource protection.

[0107] Read-write locks allow multiple threads to read shared resources simultaneously, but only one thread is allowed to perform a write operation at any given time. This mechanism significantly improves system concurrency performance while ensuring data consistency. Therefore, read-write locks have significant advantages in embedded environments where resource access is frequent and read operations are dominant, providing theoretical support and a practical foundation for efficient resource management in embedded systems.

[0108] (2) Transaction locks;

[0109] Considering the limited system resources in the airborne environment, two types of locks are proposed: read locks (shared locks) and write locks (exclusive locks). Concurrent operations can be divided into four types: read-read, read-write, write-read, and write-write. At least concurrent read-read operations are allowed, which improves the concurrency capability while ensuring data consistency with locks. The lock compatibility matrix shown in Table 1 below can be obtained.

[0110] Table 1. Lock compatibility matrix (new lock requests between different transactions)

[0111]

[0112] Table 1 describes the concurrency of locking operations between different transactions on the same data item. Concurrency is only allowed when different transactions all hold read locks on the same data item; otherwise, newly requested locks cannot be granted. When the same transaction locks the same data item, lock escalation may occur. For example, a transaction might initially request a read lock on a data item and be granted one upon successful request. However, if the transaction subsequently needs to modify the data item, lock escalation will occur, changing the lock from a read lock to a write lock. During lock escalation, the lock compatibility matrix described above must be satisfied.

[0113] Transaction lock granularity: Regarding the issue of transaction lock granularity, different lock granularities have significantly different impacts on database system performance. Locking at a smaller granularity (e.g., rows) can increase system concurrency, but it incurs significant system overhead, thus impacting performance because a smaller granularity increases the number of locks that may be generated by operations. Locking at a larger granularity (e.g., tables) is quite expensive because locking the entire table restricts other transactions from accessing any part of the table, but the overhead is lower because fewer locks need to be maintained. Given the relatively low concurrency requirements in onboard database environments, a page-level locking mechanism is considered, using page-level locking to achieve transaction concurrency control.

[0114] 2. Transaction Concurrency Control Protocol Selection: Concurrency control protocols can be broadly categorized into two types: optimistic and pessimistic. Optimistic concurrency control protocols do not perform checks at the start of transaction execution, assuming that concurrent transactions will not conflict. If data conflicts occur during execution, certain strategies (such as transaction rollback) are then implemented. This approach is suitable for low-conflict scenarios and offers good performance, but in high-conflict scenarios, it may lead to a large number of transaction rollbacks, impacting system performance. Pessimistic concurrency control protocols, on the other hand, check for conflicts before transaction execution, and only execute if no conflicts are found. This approach is suitable for high-concurrency scenarios and frequent data conflict scenarios.

[0115] In airborne environments, aviation systems typically require a certain level of concurrency and real-time performance. Optimistic concurrency control protocols, however, can lead to unstable rollbacks under high conflict conditions, reducing system reliability and making them unsuitable for such environments. MVCC (Multi-Version Concurrency Control) improves concurrency and read performance by providing each transaction with a different version of the data, avoiding the use of read-write locks. However, MVCC requires storing version information and periodically cleaning up expired versions, which is unsuitable for airborne environments due to storage and resource constraints.

[0116] In contrast, pessimistic concurrency control protocols, such as two-phase locking, employ strict locking mechanisms during transaction execution to ensure concurrent execution and data consistency. Although pessimistic concurrency control protocols may introduce some overhead, such as lock management and resource contention, they effectively avoid data conflicts and concurrency issues, providing reliable transaction performance; therefore, they are adopted. Considering the high consistency requirements of aviation data, a strict two-phase locking protocol is proposed. Besides requiring locking to be two-phased, it also requires that all exclusive locks held by a transaction can only be released after the transaction is committed. This requirement ensures that any data written by an uncommitted transaction is locked with an exclusive lock before the transaction is committed, preventing other transactions from reading this data. Therefore, in the GROWING phase, transactions can acquire both read and write locks, but can only release read locks; in the SHRINKING phase, transactions can only acquire read locks, not write locks, and all write locks can only be released after the transaction is committed or aborted.

[0117] 3. Transaction isolation level selection: There are four transaction isolation levels: Read Uncommitted, Read Committed, Repeatable Read, and Serializable.

[0118] Read Uncommitted does not meet the strict requirements for data reading in an airborne environment. It allows transactions to see the execution results of other uncommitted transactions, guaranteeing a lower level of consistency and making it unsuitable for concurrency control in an airborne environment. Repeatable Read and Serializable, on the other hand, have stricter concurrency requirements, requiring a higher cost to guarantee stricter consistency, while also resulting in lower transaction concurrency performance.

[0119] In airborne environments, the immediate access and frequent updates of real-time data are critical requirements. Therefore, adopting the Read Committed isolation level is an effective strategy because it provides a balance between concurrency performance and data consistency. The Read Committed isolation level allows transactions to read modifications made by other committed transactions, ensuring data real-time performance and consistency. During transaction execution, this isolation level does not allow the current transaction to read modifications being made by other transactions, thus ensuring that the data read by the current transaction is the latest and committed, effectively preventing dirty reads. Furthermore, the Read Committed isolation level is particularly suitable for frequent data updates in airborne systems because it allows a certain degree of concurrent operations without sacrificing data accuracy. Under this isolation level, transactions can only see the latest data state that has been committed by other transactions when reading data, which is a key factor in ensuring data accuracy when the airborne system handles critical operations. This design satisfies the need for immediate access to real-time data while ensuring rapid operational response, significantly impacting the overall performance and efficiency of the airborne system.

[0120] 4. Transaction Rollback Mechanism: For read-heavy, write-light applications in onboard environments, a mechanism similar to shadow pages is adopted to ensure atomicity and consistency during concurrent transactions. This effectively improves the speed of transaction rollback, thereby reducing the impact of transaction rollback on high-priority transactions. Specifically, when a transaction modifies a data page, it not only updates the actual data page but also saves the old page before the transaction's modification in memory as a shadow page of the newly modified dirty page, maintained using an OldPage hash table.

[0121] like Figure 5 As shown, this method of saving shadow pages in memory, rather than on disk, allows for fast access and recovery. When conflicts occur between different transactions, causing a transaction to need to be rolled back, since all pages modified by that transaction are locked by the lock manager's transaction locks, the previously saved shadow pages can be used to overwrite the current data pages, restoring the data to its consistent state before the modification.

[0122] Example:

[0123] 1. Implementation of system locks and transaction locks;

[0124] (1) System lock;

[0125] Considering that onboard embedded databases typically face a "read-heavy, write-light" usage scenario, this research implements a read-write lock that favors read operations. This lock design allows multiple read operations to execute concurrently, while write operations can only be executed when there are no read operations, thereby reducing the blocking of read operations by write operations and optimizing system response time and throughput.

[0126] The implementation principle of system locks is as follows: Figure 1 As shown, this mechanism uses a counter variable to track the number of readers who have successfully acquired a read lock. During the read lock acquisition process, only the first reader to request a read lock will actually acquire the lock, while other subsequent readers will only increment the counter and mark the current lock state as "read mode". When a write lock is requested, the system will directly call the interface to acquire the write lock, and after successful acquisition, set the current lock state to "write mode". During the lock release process, if it is a read lock, the actual lock release operation is performed by the last reader to leave; if it is a write lock, the write lock will be released immediately after the write operation is completed.

[0127] In the Tianmai ACoreOSMP653 operating system, system lock management requires a special resource pool mechanism. For example... Figure 2 As shown, the allocation and release of system lock resources are centrally managed through an independent lock pool. During database system initialization, the system automatically initializes the lock pool and dynamically calculates its capacity based on the size of the cache pool. This method ensures efficient allocation and reclamation of lock pool resources while avoiding the performance overhead caused by frequent lock creation and destruction.

[0128] (2) Transaction locks;

[0129] To effectively manage transaction locks, the system employs a dedicated lock manager for centralized and unified management. Under a page-level locking framework, the lock manager maintains a lock table for each page that needs to be accessed, storing it in memory using a HashMap based on the mapping between page number and the lock table. The lock table stores the current lock status of the page and information about different transactions requesting locks on that page. The lock table structure is as follows: Figure 3 As shown, it specifically includes four parts: group mode, wait bit, number of transactions granted the current lock, and list.

[0130] ① The group schema summarizes the most stringent conditions a lock faces when a transaction requests a new lock on page A. When a transaction requests a lock on page A, instead of comparing the lock request with each lock held by other transactions on that page one by one, the grant / deny decision can be simplified by comparing only the request with the group schema. The specific rules are as follows:

[0131] aS indicates that only read locks are held, and there may be multiple read locks.

[0132] bX indicates that there is only one write lock and no other locks.

[0133] ② The wait bit indicates that at least one transaction is waiting for a lock on page A.

[0134] ③ Number of transactions that have been granted the current lock. Records how many transactions have been granted the current lock in the current group mode.

[0135] ④ A list describing all transactions that either currently hold a lock on page A or are waiting for a lock on page A. Useful information in each list item may include:

[0136] a. The transaction ID that holds the lock or is waiting for the lock.

[0137] b. The type of lock requested for the transaction.

[0138] c. Whether the transaction holds the lock or waits for the lock.

[0139] All these list items on page A are stored in an array called ArrayList.

[0140] 1) Lock application;

[0141] Suppose transaction T requests a lock on page A. The handling of lock requests between different transactions can be categorized into the following scenarios:

[0142] ① If there is no lock entry for page A, then there is definitely no lock on page A, so the corresponding entry is created and the request is granted.

[0143] ② If a lock table entry for page A exists, then the group schema is found. According to the grant / deny rules of the group schema, if a read lock already exists on page A, another read lock can be granted. In this case, transaction T's entry in the list will have "wait=No", while the write lock will be denied, and an entry representing transaction T's lock request will be added to the list with "wait=Yes". If a write lock already exists on page A, then no other lock can be granted, and transaction T's entry in the list will have "wait=Yes".

[0144] The above describes the handling of lock requests between different transactions. For the same transaction T, if it has already acquired a read lock on page A and now needs to upgrade the lock, if the current lock table group mode is read lock and there is only one read lock, then a write lock can be directly granted to transaction T. The locking mode of transaction T's item in the list will be changed to write lock, and the group mode needs to be changed to write lock. Otherwise, it will not be granted. The locking mode of transaction T's item in the list will be changed to write lock, and the wait bit will also be changed to "wait=Yes".

[0145] 2) Releasing the lock;

[0146] Suppose transaction T unlocks page A. The entry for page A related to transaction T in the list will be deleted. If other entries still exist in the list, a new group pattern needs to be found according to the first-come, first-served principle. If the new group pattern is a write lock, there will be no other locks. However, if it's a read lock, it's necessary to determine if there are any other read locks.

[0147] 3) Deadlock detection;

[0148] Because a lock-based concurrency control method is used, and locks are divided into multiple granularities, locking leads to mutual waiting, which directly results in deadlock. Since both read and write locks are used, a deadlock like R(X)W(Y)-R(Y)W(X) can occur, preventing any concurrent transaction from continuing. Figure 4 As shown, a deadlock occurred when transaction T1 and transaction T6 were waiting for each other.

[0149] There are two main methods for handling deadlock: wait graphs and wait timeout mechanisms. The first method uses a wait graph to represent the waiting relationships between transactions. A wait graph is a directed graph, such as... Figure 4 As shown, T1->T6 means that transaction T1 is waiting for transaction T6 to release resources. In the deadlock detection thread, a depth-first search (DFS) algorithm is used to periodically check for cycles in the current wait graph. When a cycle exists, it indicates a deadlock, requiring the selection of transactions to abort and break the deadlock. However, this method requires maintaining additional information and necessitates a separate thread in the database system to run the wait graph detection algorithm independently. Considering the resource constraints in the onboard environment, the read-heavy, write-light application scenario, and the low conflict rate between transactions, the second approach was adopted to solve the deadlock problem, reducing additional information maintenance and system overhead.

[0150] 2. The strict two-phase lockdown agreement was implemented;

[0151] Strict two-phase locking protocols require that read locks or write locks can be acquired during the lock growth phase. Read locks can be released immediately after use, while write locks must be held until the transaction is committed. Therefore, during transaction execution, read locks are released immediately to reduce lock holding time, while write locks must be released uniformly after the transaction is committed to ensure data consistency.

[0152] The airborne embedded database system uses a B+ tree as the main index structure, dynamically organizes the disk file structure, and maintains the orderly data records. The following will explain the implementation details of the strict two-phase locking protocol for the four operations of querying, inserting, deleting, and updating the main index B+ tree.

[0153] (1) Query operation;

[0154] B+ tree query operation process in concurrent scenarios Figure 6 As shown.

[0155] ① Read operations start from the root node, first acquiring the system read lock on the root node, and then acquiring the transaction read lock on the root node. Figure 6 (Lines 02-04)

[0156] ② Immediately afterwards, the read operation first acquires the system read lock on the corresponding child node based on the query conditions, then acquires the transaction read lock, and finally releases the parent node's transaction read lock and system read lock. Figure 6 (Lines 06-15).

[0157] ③ Repeat step ② above until a leaf node that meets the conditions is found, which is... Figure 6 The loop within the B+ tree. However, in leaf nodes, a transaction read lock must be acquired before a system read lock. This is because in non-leaf nodes, the locking strategy of "top-down, left-to-right" can directly prevent deadlocks at the system lock level. Since B+ trees require traversing leaf nodes from left to right using a cursor, this process may conflict with the "top-down" locking process when locking leaf nodes, leading to deadlocks. This deadlock problem cannot be directly resolved at the system lock level, so a transaction lock must be acquired before a system lock, utilizing the deadlock detection mechanism of the transaction lock manager to detect and resolve deadlocks.

[0158] ④ Finally, after reading the contents of the leaf node, release the system read lock and transaction read lock on the leaf node. Figure 6 (Line 18). Because the read operation releases the lock of the parent node only after acquiring the lock of the child node, it will not read a tree node that is being modified, nor will it result in the key-value pair of a child node being moved to another node after the child node is located.

[0159] The above outlines the complete process of a B+ tree query operation in a concurrent scenario. During a transaction's read operation, system read locks protect the physical structure of the B+ tree, while transaction read locks protect the data records. Both system read locks and transaction read locks are released immediately after use and do not need to be held until the transaction commit phase. Figure 6 (See lines 14, 15, and 18). This operation method complies with the requirements of a strict two-phase locking protocol, thereby effectively ensuring data consistency and system concurrency.

[0160] (2) Insert / delete operations;

[0161] In implementing a "top-down" locking approach, for insertion or deletion operations, a write lock is applied to the tree nodes being traversed before reaching the branch being modified. This method can block other operations from accessing the corresponding tree nodes to some extent. However, this blocking overhead increases further when write operations require frequent readings of tree nodes from disk into memory, resulting in high I / O latency.

[0162] In airborne environments, frequent read operations and infrequent write operations are the primary scenarios. To improve read concurrency, write operations employ an optimistic-then-pessimistic locking strategy. In other words, write operations typically do not alter the tree structure, only affecting the target leaf node. Nodes along the path do not require write operations. If, upon reaching the target leaf node, it is discovered that a write operation would cause a change in the tree structure, locking restarts from the root node, adopting a pessimistic strategy, assuming that a write operation will cause a change in the tree structure. The specific process is as follows: Figure 7 As shown.

[0163] ① In practical applications, write operations generally do not modify non-leaf nodes along the path, so they do not affect read operations accessing the same nodes. Therefore, when locking a B+ tree, a write operation first uses an optimistic strategy to set the lock to a query state. The specific process is similar to that of a query operation; please refer to [reference needed]. Figure 7 .

[0164] ② Upon reaching a leaf node, first acquire a transaction read lock to determine if the node is safe, i.e., whether the operation will cause modifications to the tree structure, such as splitting or merging the node. If the node is safe, upgrade the transaction read lock to a transaction write lock, and then acquire a system write lock, thus completing the locking process. If the node is not safe, release all locks and continue with subsequent steps, using a pessimistic strategy to re-acquire locks starting from the root node.

[0165] ③ Under the pessimistic strategy, write operations also start from the root node, first acquiring the system write lock on the root node, and then adding the locked node to the transaction's write lock node set. Figure 7 (Lines 04-06)

[0166] ④ Next, the write operation first acquires the system write lock on the child node, and then determines whether the child node is a safe node. If the child node is a safe node, the write operation immediately releases the system write lock on the ancestor node (which may contain multiple nodes); otherwise, it temporarily holds the system write lock on the parent node and adds that node to the transaction's write lock node set. This process is repeated until a leaf node is found (…). Figure 7 (Lines 07-19)

[0167] ⑤ Upon reaching a leaf node, it is necessary to acquire a transaction write lock first, and then acquire a system write lock. Figure 7(Lines 09-11).

[0168] ⑥ Since the system write lock on the non-leaf nodes was not acquired simultaneously with the transaction write lock, it is necessary to acquire transaction write locks separately on all locked non-leaf nodes. Figure 7 (Line 20). This is because non-leaf nodes may release write locks on ancestor nodes during the locking process. If a transaction write lock is acquired prematurely, under the read committed isolation level, this would cause the transaction to enter the shrinking phase early, preventing subsequent locking and thus hindering the locking process. Therefore, after finding a leaf node, it is necessary to traverse the transaction's write lock node set and acquire the transaction write locks on non-leaf nodes sequentially, following the same "top-down" locking approach.

[0169] ⑦ After completing the above steps, the write operation holds both system write locks and transaction write locks on all tree nodes of the modified branch, thus preventing other read / write operations from accessing the branch. Finally, the write operation releases the system write lock on the branch after modifying its contents, while the transaction write lock is released only after the transaction is committed or rolled back.

[0170] The above describes the execution process of insertion and deletion operations on a B+ tree in a concurrent scenario. Figure 7 Lines 1-22 in the diagram represent the growth phase of a transaction. During this phase, a transaction can acquire both read and write locks, and is allowed to release read locks. However, write locks must be held until the transaction is committed or rolled back. This approach strictly adheres to the strict two-phase locking protocol, ensuring that lock management complies with protocol requirements throughout the transaction's lifecycle, thereby guaranteeing data consistency and system concurrency.

[0171] (3) Update operation;

[0172] In concurrent scenarios, the B+ tree update operation is similar to the query operation, as detailed below. Figure 8 As shown.

[0173] Update operations use an in-place approach, modifying data without altering the B+ tree structure. A key difference between update and query operations lies in the locking process at leaf nodes. Update operations first acquire both transaction write locks and system write locks on the leaf nodes. After the operation, the system write lock is released immediately, while the transaction write lock is held for a longer period, remaining until the transaction is committed. Specifically... Figure 8 Lines 1-18 in the diagram represent the growth phase of a transaction. During this phase, a transaction can acquire and hold read locks or write locks, and then release read locks. The subsequent part enters the shrinking phase. This process strictly follows the strict two-phase locking protocol, ensuring that lock management complies with the protocol requirements throughout the transaction's lifecycle, thereby guaranteeing data consistency and effectively controlling concurrency.

[0174] 3. Read committed isolation level implementation;

[0175] In the Read Committed isolation level implementation, transactional read locks are released immediately after use. When a transaction reads the same record again, it needs to reacquire the transactional read lock. Transactional write locks, on the other hand, are held until the transaction commits or rolls back. To further clarify the basic implementation details of the Read Committed isolation level, the following will describe the four operations of querying, inserting, deleting, and updating the primary index B+ tree.

[0176] (1) Query operation;

[0177] According to the read-committed isolation level, a transaction read lock is released immediately after use. This ensures that a transaction does not hold a lock after reading node data, allowing other transactions to concurrently read or modify the data. In onboard database systems, using transaction read locks to lock nodes effectively prevents reading uncommitted content. The function of transaction read locks is to maintain data read consistency and prevent other transactions from modifying the same node. By using transaction read locks, transactions can ensure data visibility while reading data, unaffected by uncommitted modifications from other transactions. Figure 6 As shown, the transaction read lock of the node is acquired first (Lines 04, 08, 12) to avoid reading data that is being modified or has not yet been committed by other transactions. After reading the data in the node, the lock is released immediately (Lines 14, 18), which is consistent with the logic of the read committed isolation level.

[0178] (2) Insert / delete operations;

[0179] According to the requirements of the Read Committed isolation level, the transaction write lock remains locked until the transaction is committed, ensuring that other transactions cannot read uncommitted content. Only after the transaction is successfully committed is the transaction write lock released, allowing other transactions to continue reading or modifying the node. The use of transaction write locks effectively prevents other transactions from reading uncommitted data, avoids dirty reads, guarantees data consistency and isolation, and also reduces the holding time of system write locks, effectively reducing the overhead of lock-based concurrency control mechanisms and improving system performance and concurrency processing capabilities.

[0180] exist Figure 7In the context of optimistic write operations and query operations, the main difference in read committed isolation lies in the fact that the transaction write locks on leaf nodes are held until the transaction is committed or rolled back, preventing other transactions from reading records modified by the current transaction. In contrast, pessimistic write operations first use system write locks to lock all nodes that need modification, and then acquire the corresponding transaction write locks one by one. After completing the relevant modification operations, the system write locks are immediately released, while the transaction write locks persist until the transaction is committed or rolled back (Line 23).

[0181] (3) Update operation;

[0182] The update and query operations are implemented using similar methods. For example... Figure 8 As shown, when reading internal nodes of a B+ tree, a transaction read lock is first acquired, and then the lock is released immediately after the read operation is completed (Lines 4, 12, 14). For leaf nodes being updated, a transaction write lock is continuously used to lock them until the transaction is committed, at which point the lock can be released (Line 19). In this way, it is ensured that other transactions cannot read uncommitted content, thereby maintaining data consistency and isolation.

[0183] 4. Transaction rollback implementation;

[0184] The above describes the system's processing procedure when the locking operation is successful. In practical applications, the system's locking mechanism follows a "top-down" locking rule, so deadlocks are usually not an issue. However, conflicting accesses to the same data item by different transactions can lead to transaction deadlocks, causing transactions of the same priority to wait for each other; or, a higher-priority transaction may preempt resources from a lower-priority transaction, requiring the lower-priority transaction to roll back. To resolve such transaction conflicts, the system needs to take rollback measures to abort one of the transactions. The specific transaction rollback process is as follows: Figure 9 As shown.

[0185] After a transaction deadlock occurs, the transaction lock manager triggers the deadlock detection mechanism and immediately rolls back the transactions that failed to acquire locks. To ensure the atomicity and consistency of transactions, when any page is modified during transaction execution, that page is backed up to the old page set. When a transaction needs to be rolled back, all modified pages are locked by transaction write locks, meaning that other transactions cannot access these pages. Therefore, in Figure 9 In the loop, all page sets locked by the transaction are accessed one by one, and the corresponding page is retrieved from the old page set according to the page ID to restore the currently modified page and restore it to the state before the transaction was executed.

Claims

1. A method for concurrency control of embedded database transactions based on the Tianmai operating system, characterized in that, Comprising the following steps: Step 1: Constructing system lock and transaction lock; In the on-board database, the database files are organized in pages, and B+ tree is used as the underlying data structure. System lock is used to protect the physical structure of B+ tree under multi-threading, and the transaction lock of the lock manager is used to implement the locking operation on the data records; Step 1-1: System lock; The system lock is implemented based on semaphore, which allows multiple threads to read shared resources at the same time, but only allows one thread to execute write operation at any time; Step 1-2: Transaction lock; Two types of read lock and write lock are adopted, and concurrent operations are divided into four types: read-read, read-write, write-read and write-write. At least read-read operation can be allowed to proceed, and the compatibility matrix of the lock is obtained; Only when different transactions have read locks on the same data item can concurrent operation be allowed, otherwise the new requested lock cannot be granted. For the same transaction, lock escalation occurs when locking the same data item; A page-based lock mechanism is adopted to realize the concurrent control of transactions by locking the page; Step 2: Selection of transaction concurrent control protocol; A pessimistic concurrent control protocol is adopted, and all exclusive locks held by a transaction must be released after the transaction is committed. Any data written by an uncommitted transaction is locked with an exclusive lock until the uncommitted transaction is committed, preventing other transactions from reading this data. Therefore, in the GROWING phase, a transaction can add read locks and write locks, but can only release read locks. In the SHRINKING phase, a transaction can only add read locks and cannot add write locks. All write locks must be released after the transaction is committed or aborted; Step 3: Selection of transaction isolation level; There are four types of transaction isolation levels, namely read uncommitted, read committed, repeatable read and serializable; Read committed isolation is adopted, which allows a transaction to read the modifications made by other committed transactions; During transaction execution, the current transaction is not allowed to read the modifications being made by other transactions; Under the read committed isolation level, a transaction can only see the latest data state that has been committed by other transactions when reading data; Step 4: Transaction rollback mechanism; When a transaction modifies a data page, it not only updates the actual data page, but also saves the old page in memory as a shadow page for the new modified dirty page, which is maintained using an OldPage hash table; The shadow page is saved in memory, not on disk. When a transaction needs to be rolled back due to conflicts between different transactions, all modified pages of the transaction are locked by the transaction lock of the lock manager, so the shadow page saved previously can be used to overwrite the current data page, making the data return to a consistent state before modification.

2. The method according to claim 1, wherein, The system lock is as follows: A counter variable is used to track the number of readers that have successfully acquired the read lock; during the acquisition of the read lock, only the first reader that requests the read lock will actually get the lock, while other subsequent readers will only increment the counter and mark the current lock state as "read mode"; when a write lock is requested, the system will directly call the interface to acquire the write lock, and after successful acquisition, the current lock state will be set to "write mode"; during the release of the lock, if it is a read lock, the actual lock release operation is performed by the last reader to leave; If it is a write lock, the write lock will be released immediately after the write operation is completed; The application and release of system lock resources are centrally managed by a separate lock pool; during the initialization of the database system, the system will automatically initialize the lock pool, and the capacity of the lock pool will be dynamically calculated according to the size of the cache pool; this method can ensure efficient allocation and recovery of lock pool resources, while avoiding the performance overhead caused by frequent lock creation and destruction.

3. The method according to claim 2, wherein, The transaction lock is as follows: A lock manager is designed to centrally and uniformly manage transaction locks; under the premise of page-based locking, the lock manager maintains a lock table for each page that needs to be accessed, and stores it in memory according to the mapping relationship between page number and lock table using HashMap; the lock table stores the current lock state of the page and the information of different transactions applying for locks on the page, including group mode, waiting bit, number of transactions granted the current lock, and list; ①When a transaction comes to apply for a lock on page A, instead of comparing the lock request with the locks held by other transactions on the page one by one, the grant / deny decision is simplified by comparing only the request with the group mode; the specific rules are as follows: a. S indicates that only read locks are held; b. X indicates that only one write lock is held and no other locks are held; ②The waiting bit indicates that at least one transaction is waiting for a lock on page A; ③The number of transactions granted the current lock; Records how many transactions have been granted the current lock under the current group mode; ④A list describes all those transactions that currently hold locks on page A or are waiting for locks on page A; the useful information in each list item includes: a. The transaction ID holding or waiting for the lock; b. The type of lock requested by the transaction; c. Whether the transaction is holding the lock or waiting for the lock; All these list items on page A are stored in an array ArrayList; 1) Lock application; Assuming that transaction T requests a lock on page A, there are several cases for handling lock applications between different transactions: ①If there is no lock table item for page A, there is definitely no lock on page A, so the corresponding table item is created and the request is granted; ②If there is a lock table item for page A, the group mode is found, and according to the grant / deny rules of the group mode, if there is already a read lock on page A, another read lock can be granted, in which case the item of transaction T in the list will have "wait = No", while the write lock will be denied and an item representing the lock request of transaction T will be added to the list with "wait = Yes"; if there is already a write lock on page A, then no other lock can be granted, and the item of transaction T in the list will have "wait = Yes"; For the same transaction T, if a read lock has been obtained on page A, and now the lock needs to be upgraded, if the group mode of the current lock table is read lock and there is only one read lock, then the transaction T can be directly granted a write lock, and the lock mode of the transaction T in the list is changed to write lock, and the group mode needs to be changed to write lock, otherwise it cannot be granted, the lock mode of the transaction T in the list is changed to write lock, and the wait bit is also changed to "wait = Yes"; 2) Lock release; Assuming that transaction T unlocks page A; the transaction T's item about page A in the list will be deleted, if there are other items in the list, then the new group mode needs to be found according to the principle of first come first served; if the new group mode is write lock, there will be no other lock, but if it is read lock, it needs to be judged whether there is other read lock; 3) Deadlock detection; The deadlock problem is solved by using the waiting timeout mechanism.

4. The method according to claim 3, wherein, The pessimistic concurrency control protocol is the strict two-phase lock protocol, which is as follows: In the growth phase of the lock, read lock or write lock can be obtained, wherein the read lock can be released immediately after use, and the write lock must be kept until the transaction is committed and then released; During the execution of the transaction, the read lock is released immediately to reduce the holding time of the lock, and the write lock is uniformly released after the transaction is committed to ensure data consistency; The strict two-phase lock protocol is described for the four operations of query, insertion, deletion and update of the primary index B+ tree; (1) Query operation; ① The read operation starts from the root node, first holds the system read lock of the root node, and then holds the transaction read lock of the root node; ② The read operation first obtains the system read lock of the corresponding child node according to the query condition, and then obtains the transaction read lock, and then releases the transaction read lock and the system read lock of the parent node; ③ Repeat the execution process of step ② until the leaf node that meets the condition is found; but in the leaf node, the transaction read lock needs to be added first and then the system read lock, and the deadlock detection mechanism of the transaction lock manager is used to detect and resolve the deadlock; ④ After reading the content of the leaf node, release the system read lock and the transaction read lock of the leaf node; When the transaction executes the read operation, the system read lock is used to protect the physical structure of the B+ tree, and the transaction read lock is used to protect the data record; the system read lock and the transaction read lock are released immediately after use, without the need to hold until the transaction commit phase; (2) Insertion / deletion operation; ① When locking the B+ tree, the write operation first uses the optimistic strategy to set the lock to the query state; ② When reaching the leaf node, first add the transaction read lock, judge whether the node is safe, that is, whether the operation will cause the split / merge of the node and other modifications of the tree structure; if the node is safe, upgrade the transaction read lock to the transaction write lock, and then add the system write lock, that is, the locking process is completed; If the node is not safe, all locks need to be released, and the subsequent steps are continued, and the pessimistic strategy is used to lock from the root node again; ③ Under the pessimistic strategy, the write operation also starts from the root node, first holds the system write lock of the root node, and adds the locked node to the transaction write lock node set; (4) Write operation: first acquire the system write lock of the child node, then determine whether the child node is a safe node; if the child node is a safe node, the write operation immediately releases the system write lock of the ancestor node, otherwise the system write lock of the parent node is temporarily kept and the node is added to the write lock node set of the transaction, and the process is repeated until a leaf node is found; (5) When a leaf node is reached, the transaction write lock is first acquired, and then the system write lock is acquired; (6) Since the transaction write lock is not acquired at the same time as the system write lock of the non-leaf node, the transaction write lock of all locked non-leaf nodes needs to be added separately; (7) The write operation releases the system write lock of the branch after modifying the content of the branch, and the transaction write lock cannot be released until the transaction is committed or rolled back; (3) Update operation; The update operation adopts an in-place update manner, that is, the data is modified without changing the B+ tree structure; in the update operation, the transaction write lock and the system write lock of the leaf node need to be acquired first; after the operation is completed, the system write lock is immediately released, and the transaction write lock can be released until the transaction is committed.

5. The method of claim 4, wherein the method further comprises: The implementation of the read committed isolation level is as follows: In the implementation of the read committed isolation level, the transaction read lock is released immediately after use; when the transaction reads the same record data again, the transaction read lock needs to be re-acquired; the transaction write lock is kept until the transaction is committed or rolled back; the four operation processes of querying, inserting, deleting and updating through the primary index B+ tree are described; (1) Query operation; According to the read committed isolation level, the transaction read lock is released immediately after use; In the airborne database system, the transaction read lock is used to lock the node, which effectively avoids reading uncommitted content; (2) Insertion / deletion operation; According to the requirement of the read committed isolation level, the transaction write lock is kept in the locked state before the transaction is committed, which ensures that other transactions cannot read uncommitted content; (3) Update operation; When reading the internal node of the B+ tree, the transaction read lock is acquired first, and then the lock is released immediately after the reading operation is completed; For the updated leaf node, the transaction write lock is continuously used for locking until the lock can be released before the transaction is committed.

6. The method of claim 5, wherein the method further comprises: The step 4 is specifically: After the transaction lock deadlock occurs, the transaction lock manager triggers the deadlock detection mechanism and immediately rolls back the transaction lock failure; in order to ensure the atomicity and consistency of the transaction, when any page is modified during the transaction execution, the page is backed up to the old page set; When the transaction needs to be rolled back, the modified page is locked by the transaction write lock; all page sets locked by the transaction are accessed one by one, and the corresponding page is retrieved from the old page set according to the page ID to restore the currently modified page to the state before the transaction execution.

7. A computer program, characterised in that, The computer program enables the computer to execute the method of any one of claims 1 to 6.

8. An electronic device, comprising: Comprise: a processor and a memory; the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory to enable the electronic device to execute the method of any one of claims 1 to 6.

9. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program, which when executed by the processor, implements the method as claimed in any one of claims 1 to 6.

10. A chip, characterized by comprising: a processor for calling and running a computer program from a memory, so that the device in which the chip is installed implements the method as claimed in any one of claims 1 to 6.

Images