Embedded database transaction concurrency control method based on sky vein operating system

Abstract

The invention discloses an embedded database transaction concurrency control method based on a sky vein operating system, and aims to solve the core problem of how to effectively utilize system resources and improve system concurrency on the basis of ensuring data consistency, reliability and safety in a resource limited environment faced by the sky vein operating system. Therefore, continuous and stable operation of the system is guaranteed. Through the design of the invention, the demand for database transaction concurrency control in an avionics system based on a sky vessel operating system can be effectively met, and the strict requirement of a new generation of avionics system is met.

Description

Technical Field

[0001] The present invention belongs to the technical field of databases, and in particular relates to an embedded database transaction concurrency control method based on the Tianmai operating system. Background Art

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

[0003] In traditional avionics systems, since the amount of data processed is relatively small, applications usually have their own independent data, and there is little demand for data sharing between applications. Even if a small amount of data needs to be shared between multiple applications, data redundancy is usually used, that is, the same data has an independent backup in each application. However, with the rapid development of various sensor technologies, the complexity of avionics systems continues to increase, and the amount of data collected by aircraft during flight is also growing explosively. This increase in data volume has made traditional data processing methods unable to meet the needs of efficient data access and processing.

[0004] Therefore, in order to meet these challenges, it is urgent to introduce specialized databases or data management modules into avionics systems to support efficient management of the explosive growth of data. These databases or data management modules must not only meet the special requirements of avionics systems, such as high security, real-time, and embeddedness, but also be able to effectively handle concurrent access to ensure data consistency and system stability.

[0005] The mainstream embedded databases on the market, such as SQLite, BerkeleyDB and Empress, perform well in ordinary scenarios, but face a series of problems and challenges in the aviation field, especially in safety-critical fields. Take SQLite as an example. This widely used SQL embedded database is known for its speed, simplicity, compactness and reliability. However, in the environment of avionics systems, which have extremely high requirements for real-time and complexity, SQLite's ability in transaction concurrency control is limited. In particular, the database-level lock mechanism it adopts has its advantages in simplifying management, but the granularity of the lock is large, which limits its concurrent processing capabilities in the application scenarios of avionics systems with high concurrency and strong real-time. Therefore, in these scenarios, SQLite is difficult to meet the strict requirements of avionics systems for high concurrency processing and real-time. Similarly, although BerkeleyDB and Empress perform well in performance and reliability, their deficiencies in embeddability, real-time and customizability make it difficult for them to fully adapt to the special needs of the aviation field. In addition, in terms of security, the use of a database management system with independent intellectual property rights and safe and controllable is crucial to ensure information security in key national security areas. In this context, it is particularly urgent and important to develop an embedded database that can meet the specific needs of aviation systems.

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

[0007] Under the Tianmai operating system, database management systems face a series of unique challenges. First, the Tianmai operating system has special requirements for database management systems, including high security, real-time and embeddedness. Second, existing technologies have great limitations in adapting to the Tianmai operating system, especially in terms of transaction concurrency control. Finally, the importance of database transaction concurrency control schemes in avionics systems cannot be ignored, because it is directly related to the concurrency, reliability and security of the database system, as well as the overall database performance and robustness.

[0008] In order to meet the needs of multiple applications in the new generation of avionics systems to access the same data through a unified interface provided by the database, while ensuring data consistency and security, the airborne embedded database must implement concurrent security for multiple data access requests. Therefore, transaction concurrency control technology in database management systems is crucial. The design concept, processing strategy, and implementation algorithm of transaction concurrency control algorithms are the key to ensuring the stable operation of database systems in high-concurrency environments. Summary of the invention

[0009] In order to overcome the shortcomings of the prior art, the present invention provides an embedded database transaction concurrency control method based on the Tianmai operating system. The core problem solved is how to effectively utilize system resources and improve system concurrency on the basis of ensuring data consistency, reliability and security in the resource-limited environment faced by the Tianmai operating system, thereby ensuring the continuous and stable operation of the system. Through the design of the present invention, the demand for database transaction concurrency control in the avionics system based on the Tianmai operating system can be effectively met, and the strict requirements of the new generation of avionics systems can be adapted.

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

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

[0012] In the onboard database, the database file is organized in pages, with B+ tree as the underlying data structure. The system lock is used to protect the physical structure security of the B+ tree under multi-threading, and the transaction lock of the lock manager is combined to implement the locking operation of data records.

[0013] Step 1-1: System lock;

[0014] Implement system locks based on semaphores, allowing multiple threads to read shared resources at the same time, but only allowing one thread to perform write operations at any time;

[0015] Step 1-2: Transaction lock;

[0016] Using two types of locks, i.e., shared locks and write locks, i.e., exclusive locks, concurrent operations are divided into four types: read-read, read-write, write-read, and write-write. At least the concurrency of read-read operations can be allowed, and the lock compatibility matrix is ​​obtained;

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

[0018] A page-based locking mechanism is used to implement transaction concurrency control by locking pages.

[0019] Step 2: Transaction concurrency control protocol selection;

[0020] A pessimistic concurrency control protocol is adopted. All exclusive locks held by a transaction can only be released after the transaction is committed. It ensures that any data written by an uncommitted transaction is locked with an exclusive lock before the uncommitted transaction is committed to prevent other transactions from reading the 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, not write locks, and all write locks must be released after the transaction is committed or aborted.

[0021] Step 3: Transaction isolation level selection;

[0022] There are four transaction isolation levels: read uncommitted, read committed, repeatable read, and serializable;

[0023] Read-committed isolation is used to allow transactions to read modifications made by other committed transactions. During transaction execution, the current transaction is not allowed to read modifications being made by other transactions.

[0024] At the read committed isolation level, a transaction can only see the latest data status that has been committed by other transactions when reading data;

[0025] Step 4: Transaction rollback mechanism;

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

[0027] Shadow pages are saved in memory rather than on disk. When a conflict occurs between different transactions and a transaction needs to be rolled back, since all modified pages of the transaction are locked by the transaction lock of the lock manager, the previously saved shadow pages can be used directly to overwrite the current data pages, returning the data to the consistency state before the modification.

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

[0029] A counting variable is used to track the number of readers who have successfully acquired the read lock. During the acquisition of the read lock, only the first reader who requests the read lock will actually obtain the lock, while other subsequent readers will only increase the count and mark the current lock state as "read mode". When a write lock is requested, the system will directly call the interface to obtain the write lock, and set the current lock state to "write mode" after successful acquisition. 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 application and release of system lock resources are centrally managed through an independent lock pool. During the database system initialization process, the system automatically initializes the lock pool and dynamically calculates the capacity of the lock pool based on the size of the cache pool; this method ensures efficient allocation and recycling of lock pool resources while avoiding the performance overhead caused by frequent lock creation and destruction.

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

[0032] Design a lock manager to centrally and uniformly manage transaction locks. Under the premise of page-based locks, 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 the page number and the lock table. The lock table stores the current lock status of the page and the information of different transactions applying for locks on the page, including 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 with the locks held by other transactions on the page one by one. The grant / reject decision is simplified by comparing only the request with the group mode; the specific rules are as follows:

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

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

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

[0037] ③The number of transactions granted the current lock; record 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 or waits for a lock;

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

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

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

[0043] 1) Lock application;

[0044] Assume that transaction T requests a lock on page A. There are several situations for the lock processing between different transactions:

[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 approved;

[0046] ② If there is a lock table entry for page A, then the group mode is found. 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 this case, the entry of transaction T in the list will have "wait = No", and the write lock will be denied. An entry indicating that transaction T applied for a lock is added to the list, and "wait = Yes"; if there is already a write lock on page A, then no other lock can be granted, and the entry of transaction T in the list will have "wait = Yes";

[0047] In the above processing of applying for locks between different transactions, for the same transaction T, if a read lock has been obtained on page A, the lock needs to be upgraded. If the current group mode of the lock table is read lock, and there is only one read lock, then the write lock can be directly granted to transaction T, and the locking mode of transaction T in the list item is changed to write lock. The group mode needs to be changed to write lock, otherwise it will not be granted. The locking mode of transaction T in the list item is changed to write lock, and the wait bit is also changed to "wait = Yes";

[0048] 2) Release of lock;

[0049] Assume that transaction T unlocks page A. The entry of transaction T on page A in the list will be deleted. If there are other entries in the list, a new group mode needs to be found according to the first-come-first-served principle. If the new group mode is a write lock, there must be no other locks. However, if it is a read lock, it is necessary to determine whether there are other read locks.

[0050] 3) Deadlock detection;

[0051] The wait timeout mechanism is used to solve the deadlock problem.

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

[0053] In 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 the lock holding time, while write locks must be released uniformly after the transaction is committed to ensure data consistency.

[0054] A strict two-phase blocking protocol is described for the four operations of query, insert, delete and update of the primary index B+ tree;

[0055] (1) Query operation;

[0056] ① The read operation starts from the root node, first holding the system read lock of the root node, and then holding the transaction read lock of the root node;

[0057] ② The read operation first obtains the system read lock of the corresponding child node according to the query conditions, then obtains the transaction read lock, and then releases the parent node 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 must be added first and then a system read lock must be added, and the deadlock detection mechanism of the transaction lock manager must be used to detect and resolve the deadlock;

[0059] ④ After reading the content of the leaf node, release the system read lock and transaction read lock of 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, and the transaction read lock is used to protect the data record. The system read lock and transaction read lock are released immediately after use and do not need to be held until the transaction commit stage.

[0061] (2) Insertion / deletion operations;

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

[0063] ② When reaching a leaf node, first add a transaction read lock to determine whether the node is safe, that is, whether the operation will cause the node to be split / merged or other tree structure modifications; if the node is safe, upgrade the transaction read lock to a transaction write lock, and then add a system write lock to complete the locking process; if the node is not safe, all locks need to be released, and the subsequent steps are continued, using a pessimistic strategy to re-lock from the root node;

[0064] ③ Under the pessimistic strategy, the write operation also starts from the root node. First, the system write lock of the root node is held, and the locked node is added to the write lock node set of the transaction;

[0065] ④ The write operation first obtains the system write lock of 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 of the ancestor node, otherwise it temporarily keeps the system write lock of the parent node and adds the node to the write lock node set of the transaction. This process is repeated until a leaf node is found;

[0066] ⑤ When reaching the leaf node, you need to first obtain the transaction write lock, and then obtain the system write lock;

[0067] ⑥Since the transaction write lock is not obtained at the same time as the system write lock of the non-leaf node, it is necessary to add transaction write locks to all locked non-leaf nodes separately;

[0068] ⑦ The write operation releases the system write lock of the branch after modifying the content of this branch. The transaction write lock can only be released after the transaction is committed or rolled back;

[0069] (3) Update operation;

[0070] The update operation uses an 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 obtain 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, and the transaction write lock will not be released until the transaction is committed.

[0071] Preferably, the read committed isolation level is implemented as follows:

[0072] In the implementation of the read committed isolation level, the transaction read lock is released immediately after use; when the transaction reads the data of the same record again, it needs to reacquire the transaction read lock; and the transaction write lock is held until the transaction is committed or rolled back. The four operation processes of query, insert, delete and update of the primary index B+ tree are described;

[0073] (1) Query operation;

[0074] According to the provisions of the read committed isolation level, the transaction read lock is released immediately after use; in the onboard database system, the transaction read lock is used to lock the node, effectively avoiding reading uncommitted content;

[0075] (2) Insertion / deletion operations;

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

[0077] (3) Update operation;

[0078] When reading the internal nodes of the B+ tree, the transaction read lock is first acquired, and then the lock is released immediately after the read operation is completed; for the updated leaf nodes, the transaction write lock is continuously used to lock them until the lock can be released before the transaction is committed.

[0079] Preferably, the step 4 is specifically:

[0080] After a transaction lock deadlock occurs, the transaction lock manager triggers the deadlock detection mechanism and immediately rolls back the transaction that failed to lock. To ensure the atomicity and consistency of the transaction, when any page is modified during the transaction execution, the page will be backed up to the old page set. When the transaction needs to be rolled back, the modified pages are all locked by the transaction write lock. All page sets locked by the transaction are accessed one by one, and the corresponding pages are 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 enables a computer to execute the above-mentioned embedded database transaction concurrency control method.

[0082] An electronic device comprises: 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, so that the electronic device executes the above-mentioned embedded database transaction concurrency control method.

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

[0084] A chip includes: a processor, which is used to call and run a computer program from a memory, so that a device equipped with the chip executes the above-mentioned embedded database transaction concurrency control method.

[0085] A computer program product includes a computer storage medium storing a computer program, wherein the computer program includes instructions executable by at least one processor, and when the instructions are executed by the at least one processor, the above-mentioned embedded database transaction concurrency control method is implemented.

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

[0087] (1) The transaction concurrency control scheme designed by the present invention adopts page-level locks. The selection of this lock granularity fully considers the constraints of limited resources in the airborne environment and the need to improve transaction concurrency. Compared with table locks or database-level locks with larger granularity, the use of locks with larger granularity will significantly limit concurrency. Although row-level locks can provide higher concurrency, they require the maintenance of more additional information, increasing the complexity and resource consumption of the system. Therefore, page-level locks, as a compromise solution, avoid the excessive overhead caused by row-level locks while ensuring appropriate concurrency, and effectively control access to database data pages, reducing conflicts between transactions, thereby improving the overall concurrency performance of the system.

[0088] (2) The transaction concurrency control scheme designed by the present invention adopts the coordinated use of physical locks and logical locks, thereby avoiding the long-term holding of physical locks during the transaction life cycle and reducing the overhead caused by locking operations during transaction concurrency.

[0089] (3) The transaction concurrency control scheme designed by the present invention is optimized and customized specifically for the domestic Tianmai operating system, especially in terms of lock management and implementation, which can fully improve the performance of the database system on the Tianmai operating system. Through the management of the lock pool, the system can reuse lock resources more efficiently, avoiding the high cost of creating and destroying operations each time a lock is requested, and improving the efficiency of transaction concurrency control. BRIEF DESCRIPTION OF THE DRAWINGS

[0090] Figure 1 System lock and unlock process: (a) acquire write lock / read lock process, (b) release write lock / read lock process;

[0091] Figure 2 This is a timing diagram for lock pool management;

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

[0093] Figure 4 This is a schematic diagram of the deadlock phenomenon;

[0094] Figure 5 Schematic diagram of transaction rollback mechanism.

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

[0096] Figure 7 Schematic diagram of the insert / delete operation process.

[0097] Figure 8 This is a schematic diagram of the update operation process.

[0098] Fig. 9 This is a diagram of the transaction rollback process. DETAILED DESCRIPTION

[0099] The present invention is further described below in conjunction with the accompanying drawings and embodiments.

[0100] In order to solve the limitations of traditional database technology in the development of airborne systems, such as large size and long delay, the present invention focuses on the transaction concurrency control of the database, and conducts in-depth design and implementation for the Tianmai operating system. The Tianmai operating system has special requirements for database management systems, including high security, real-time and embeddedness, making it difficult for traditional transaction concurrency control solutions to meet the needs of avionics systems.

[0101] The core problem that the present invention aims to solve is how to effectively utilize system resources and improve system concurrency on the basis of ensuring data consistency, reliability and security in the resource-limited environment faced by the Tianmai operating system, thereby ensuring the continuous and stable operation of the system. Through the innovative design of the present invention, it can effectively meet the demand for concurrent control of database transactions in the avionics system based on the Tianmai operating system and adapt to the strict requirements of the new generation of avionics systems.

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

[0103] 1. System lock and transaction lock: In the onboard database, the database file is organized in pages, with B+ tree as the underlying data structure. Based on this premise, the physical content (data structure) and logical content (data record) of the B+ tree are clearly distinguished. The data record changes the logical content, while the splitting and merging of nodes belong to the physical content. The "top-to-bottom, left-to-right" Crab Protocol locking idea is adopted, and the system lock is used to protect the structural security of the B+ tree under multi-threading. The transaction lock of the lock manager is combined to implement the locking operation of the data record, so that the system lock does not need to be held for a long time, and the transaction lock is consistent with the life cycle of the transaction, reducing the locking overhead, thereby achieving high transaction concurrency in a multi-threaded environment.

[0104] (1) System lock;

[0105] In the Linux operating system environment, in order to effectively protect shared resources, the lock mechanism provided by the operating system is usually used, such as the pthread library based on the POSIX interface, for synchronization and mutual exclusion operations between threads. However, since the Tianmai operating system does not support the POSIX interface, it is necessary to design and encapsulate an adaptive lock interface to meet the system's specific functional requirements for the lock mechanism.

[0106] As a resource access control mechanism, semaphores are widely used in synchronization and mutual exclusion scenarios between threads. In the ARINC653 standard, only counting semaphore types are defined, while the partition operating system of the Tianmai ACoreOSMP653 operating system V1.0.6.03 version expands the mutual exclusion semaphore function based on the APEX semaphore, and adds a new mutual exclusion semaphore type to support mutual exclusion access to critical resources within the partition. However, the function of the mutual exclusion semaphore is relatively limited, and it can only achieve complete mutual exclusion access to resources, lacking flexibility. For this reason, this study chooses to implement read-write locks based on semaphores to meet higher requirements for shared resource protection.

[0107] The design of the read-write lock allows multiple threads to read shared resources at the same time, but only one thread is allowed to perform write operations at any time. This mechanism significantly improves the concurrency performance of the system while ensuring data consistency. Therefore, the read-write lock has significant applicability advantages in embedded environments where resource access is frequent and read operations dominate, providing theoretical support and practical basis for efficient resource management of embedded systems.

[0108] (2) Transaction lock;

[0109] Taking into account the limited system resources in the airborne environment, it is planned to adopt two types of read locks (shared locks) and write locks (exclusive locks). Then the concurrent operations can be divided into four types: read-read, read-write, write-read, and write-write. At least the concurrency of read-read operations can be allowed, so that the concurrency capability can be improved while using locks to ensure data consistency. The lock compatibility matrix shown in Table 1 below can be obtained.

[0110] Table 1 Lock compatibility matrix (application of new locks between different transactions)

[0111]

[0112] Table 1 describes the concurrency of locking operations between different transactions on the same data item. Concurrent operations are allowed only when different transactions have read locks on the same data item. In other cases, newly requested locks cannot be granted. When the same transaction locks the same data item, lock escalation may occur. For example, a transaction initially requests a read lock on a data item, and is granted a read lock after the request is successful. In the subsequent operation, the transaction needs to modify the data item, which will cause the lock to be upgraded from a read lock to a write lock. In the process of lock escalation, the compatibility matrix of the above locks needs to be satisfied.

[0113] Transaction lock granularity: Regarding the issue of transaction lock granularity, it is considered that different lock granularities have a significant difference in the impact on the performance of the database system. Locking resources at a smaller granularity (such as rows) can increase the concurrency of the system, but it requires a larger system overhead, which will also affect the performance of the system, because the smaller the lock granularity, the greater the number of locks that may be generated by the operation; locking a larger granularity (such as a table) is quite expensive, because locking the entire table restricts other transactions from accessing any part of the table, but the required overhead is lower because fewer locks need to be maintained. Given the relatively low requirements for concurrency in the airborne database environment, consider using a page-based lock mechanism to implement transaction concurrency control by locking pages.

[0114] 2. Transaction concurrency control protocol selection: Concurrency control protocols can be roughly divided into two categories: optimistic and pessimistic. The optimistic concurrency control protocol does not check at the beginning of transaction execution, and believes that concurrent transactions will not conflict. Once a data conflict occurs during the execution process, a certain strategy (such as transaction cancellation, etc.) will be adopted. It is suitable for low-conflict scenarios and has good performance, but in high-conflict scenarios, it may cause a large number of transactions to roll back, affecting system performance. The pessimistic concurrency control protocol checks for conflicts before transaction execution and executes only if there is no conflict. It is suitable for scenarios with high concurrency and frequent data conflicts.

[0115] In an airborne environment, aviation systems usually require a certain degree of concurrency and real-time performance, and optimistic concurrency control protocols may cause unstable rollbacks in high-conflict situations, reducing system reliability, and are therefore not suitable for such environments. The MVCC (Multi-Version Concurrency Control) mechanism avoids the use of read-write locks and improves concurrency and read performance by providing different versions of data for each transaction. However, MVCC requires storing version information and regularly clearing expired versions, which is not applicable in an airborne environment due to storage and resource limitations.

[0116] In contrast, pessimistic concurrency control protocols, such as the two-phase locking protocol, use a strict locking mechanism during the execution of transactions to ensure concurrent execution of transactions and data consistency. Although pessimistic concurrency control protocols may introduce certain overhead, such as lock management and resource competition, they can effectively avoid data conflicts and concurrency problems and provide reliable transaction performance, so pessimistic concurrency control protocols are adopted. Considering that aviation data has high requirements for data consistency, a strict two-phase locking protocol is proposed. In addition to requiring the locking to be two-phase, it also requires that all exclusive locks held by the transaction must 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 to prevent other transactions from reading the 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, not write locks, and all write locks must be released after the transaction is committed or aborted.

[0117] 3. Transaction isolation level selection: There are four transaction isolation levels, namely 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, which guarantees a low level of consistency and is not suitable for concurrency control in an airborne environment. Repeatable Read and Serializability have stricter requirements for concurrency, requiring a higher cost to ensure stricter consistency, and at the same time, the transaction concurrency performance is lower.

[0119] In an airborne environment, instant reading and frequent updates of real-time data are key requirements. To this end, adopting the read committed isolation level is an effective strategy because it provides a balance between concurrent performance and data consistency. The read committed isolation level allows transactions to read modifications made by other committed transactions, ensuring the real-time and consistency of data. During the execution of a transaction, this isolation level does not allow the current transaction to read modifications being made by other transactions, thereby ensuring that the data read by the current transaction is the latest and committed, effectively preventing dirty reads. In addition, the read committed isolation level is particularly suitable for frequent updates of data in airborne systems because it allows a certain degree of concurrent operations without sacrificing data accuracy. At this isolation level, when a transaction reads data, it can only see the latest data status that has been committed by other transactions, which is a key factor in ensuring data accuracy when the airborne system is processing critical operations. Such a design not only meets the need for instant access to real-time data, but also ensures rapid response to operations, which has an important impact on improving the overall performance and efficiency of airborne systems.

[0120] 4. Transaction rollback mechanism: For the application scenarios with more reads and less writes in the airborne environment, a mechanism similar to shadow pages is used to ensure the atomicity and consistency of the transaction concurrency process, which can effectively improve 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 will not only update the actual data page, but also save the old page before the transaction modification in the memory as the shadow page of the newly modified dirty page, and use the OldPage hash table for maintenance.

[0121] like Figure 5 As shown in the figure, this shadow page is saved in memory instead of on disk, which allows for quick access and recovery. When conflicts occur between different transactions and a transaction needs to be rolled back, since all modified pages of the transaction are locked by the transaction lock of the lock manager, the previously saved shadow page can be used to directly overwrite the current data page, returning the data to the consistency state before the modification.

[0122] Example:

[0123] 1. System lock and transaction lock implementation;

[0124] (1) System lock;

[0125] Considering that airborne embedded databases usually face the usage scenario of "more reads and fewer writes", this study implements a read-write lock that is biased towards read operations. The lock design allows multiple read operations to be executed 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 the response time and throughput of the system.

[0126] The implementation principle of system lock is as follows Figure 1 As shown in the figure. This mechanism uses a counting variable to track the number of readers who have successfully acquired the read lock. During the acquisition of the read lock, only the first reader who requests the read lock will actually obtain the lock, while other subsequent readers will only increase the count and mark the current lock state as "read mode". When the write lock is requested, the system will directly call the interface to obtain the write lock, and set the current lock state to "write mode" after successful acquisition. 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, the management of system locks requires the use of a special resource pool mechanism. Figure 2 As shown in the figure, the application and release of system lock resources are centrally managed through an independent lock pool. During the database system initialization process, the system automatically initializes the lock pool and dynamically calculates the capacity of the lock pool based on the size of the cache pool. This method can ensure efficient allocation and recycling of lock pool resources while avoiding the performance overhead caused by frequent lock creation and destruction.

[0128] (2) Transaction lock;

[0129] In order to effectively manage transaction locks, the system has specially designed a lock manager to centrally and uniformly manage transaction locks. Under the premise of page-based locks, 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 numbers and lock tables. The lock table stores the current lock status of the page and the information on locks applied by different transactions on the 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 mode summarizes the most stringent conditions faced by a lock when a transaction applies for a new lock on page A. 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 / reject decision can be simplified by comparing only the request with the group mode. The specific rules are as follows:

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

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

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

[0134] ③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.

[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 or is waiting for a lock.

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

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

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

[0140] 1) Lock application;

[0141] Assume that transaction T requests a lock on page A. There are several situations for the lock processing between different transactions:

[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 approved.

[0143] ② If there is a lock table entry for page A, then the group mode is found. 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 this case, the entry of transaction T in the list will have "wait = No", and the write lock will be denied. An entry indicating that transaction T applied for a lock 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 entry of transaction T in the list will have "wait = Yes".

[0144] The above processing for applying for locks between different transactions, for the same transaction T, if a read lock has been obtained on page A, now the lock needs to be upgraded. If the current group mode of the lock table is read lock, and there is only one read lock, then the write lock can be directly granted to transaction T, and the locking mode of transaction T in the list item is 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 in the list item is changed to write lock, and the wait bit is also changed to "wait = Yes".

[0145] 2) Release of lock;

[0146] Assume that transaction T unlocks page A. The entry of transaction T on page A in the list will be deleted. If there are other entries in the list, a new group mode needs to be found on a first-come, first-served basis. If the new group mode is a write lock, there will be no other locks, but if it is a read lock, it is necessary to determine whether there are other read locks.

[0147] 3) Deadlock detection;

[0148] Since the concurrency control method based on locks is adopted and the locks are divided into multiple granularities, the blocking causes mutual waiting, which directly leads to deadlock. Since the two types of locks, read lock and write lock, are used, deadlock such as R(X)W(Y)-R(Y)W(X) will occur, resulting in no concurrent transaction being able to continue to execute, such as Figure 4 As shown, transactions T1 and T6 wait for each other, resulting in a deadlock problem.

[0149] There are two main ways to handle deadlock: wait graph and wait timeout mechanism. The first way is to use a wait graph to represent the waiting relationship between transactions. The 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, the depth-first search algorithm (DFS) is used to periodically check whether there is a cycle in the current waiting graph. When there is a cycle in the waiting graph, it means that a deadlock has occurred and a transaction needs to be selected to abort to break the deadlock. However, this method requires the maintenance of additional information and requires a separate thread in the database system to independently run the waiting graph detection algorithm. Considering the resource limitations in the airborne environment and the application scenarios with more reads and less writes, as well as the characteristics of fewer conflicts between transactions, the second method is used to solve the deadlock problem to reduce additional information maintenance and system overhead.

[0150] 2. Strict two-stage blocking protocol implementation;

[0151] The strict two-phase locking protocol requires that read locks or write locks can be acquired during the lock growth phase, where 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 the 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 B+ tree as the main index structure, dynamically organizes the disk file structure, and maintains the order of data records. The following will explain the implementation details of the strict two-phase blocking protocol for the four operations of query, insert, delete and update of the main index B+ tree.

[0153] (1) Query operation;

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

[0155] ① The read operation starts from the root node, first holding the system read lock of the root node, and then holding the transaction read lock of the root node ( Figure 6 (Line 02-04).

[0156] ② Next, the read operation first obtains the system read lock of the corresponding child node according to the query conditions, then obtains the transaction read lock, and then releases the parent node transaction read lock and system read lock ( Figure 6 Line 06-15).

[0157] ③ Repeat the execution process in step ② above until a leaf node that meets the conditions is found. Figure 6 However, in the leaf nodes, it is necessary to add a transaction read lock first and then a system read lock. This is because the "top to bottom, left to right" locking idea is met in non-leaf nodes, which can directly avoid the occurrence of deadlock at the system lock level. Since the B+ tree needs to use a cursor to traverse the leaf nodes from left to right, this process may cause a conflict with the "top to bottom" locking process when locking the leaf nodes, resulting in a deadlock. This deadlock problem cannot be directly solved at the system lock level, so it is required to add a transaction lock first and then a system lock, and use the deadlock detection mechanism of the transaction lock manager to detect and resolve the deadlock.

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

[0159] The above content outlines the complete process of B+ tree query operations in concurrent scenarios. When a transaction performs a 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 transaction read lock are released immediately after use, and do not need to be held until the transaction commit phase ( Figure 6 This operation mode meets the requirements of the strict two-phase blocking protocol, thus effectively ensuring data consistency and system concurrency.

[0160] (2) Insertion / deletion operations;

[0161] In the "top-down" locking approach, for insert or delete operations, a write lock is applied to the tree nodes passed before reaching the modified branch. This approach will block other operations from accessing the corresponding tree nodes to a certain extent. However, this blocking overhead will be further increased when write operations need to frequently read tree nodes from disk to memory, resulting in higher I / O latency.

[0162] In an airborne environment, frequent read operations and fewer write operations are the main scenarios. In order to improve the concurrency of read operations, write operations adopt an optimistic-first-pessimistic locking strategy. In other words, write operations usually do not change the structure of the tree, but only affect the target leaf node. Nodes on the path do not need to be written. If it is found that the write operation will cause the tree structure to change when reaching the target leaf node, then the lock will be restarted from the root node, and a pessimistic strategy will be adopted. By default, write operations will cause changes in the tree structure. The specific process is as follows Figure 7 shown.

[0163] ① In actual application scenarios, in most cases, write operations do not modify non-leaf nodes in the path, so they will not affect read operations that access the same nodes. Therefore, when a write operation locks a B+ tree, an optimistic strategy is first used to set the lock to the query state. The specific process is similar to the query operation, which can be referred to Figure 7 .

[0164] ② When reaching a leaf node, first add a transaction read lock to determine whether the node is safe, that is, whether the operation will cause the node to split / merge or modify the tree structure. If the node is safe, upgrade the transaction read lock to a transaction write lock, and then add a system write lock to complete the locking process. If the node is not safe, all locks need to be released, and the subsequent steps are continued, using a pessimistic strategy to re-lock from the root node.

[0165] ③ Under the pessimistic strategy, the write operation also starts from the root node. First, the system write lock of the root node is held, and the locked node is added to the write lock node set of the transaction ( Figure 7 (Line 04-06).

[0166] ④ Next, the write operation first obtains the system write lock of 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 of the ancestor node (which may contain multiple nodes). Otherwise, the system write lock of the parent node is temporarily retained, and the node is added to the write lock node set of the transaction. This process is repeated until a leaf node ( Figure 7 Line 07-19).

[0167] ⑤ When reaching the leaf node, you need to first obtain the transaction write lock, and then obtain the system write lock ( Figure 7Line 09-11).

[0168] ⑥Since the transaction write lock is not obtained at the same time as the system write lock of the non-leaf node, it is necessary to add transaction write locks to all locked non-leaf nodes separately ( Figure 7 Line 20 in the figure). This is because non-leaf nodes release the write lock of their ancestor nodes during the locking process. If the transaction write lock is acquired in advance, then at the read committed isolation level, this will cause the transaction to enter the reduction phase in advance, resulting in the inability to lock in the subsequent process and the inability to satisfy the subsequent locking process. Therefore, after finding the leaf node, it is necessary to traverse the transaction write lock node set and acquire the transaction write locks of non-leaf nodes in turn, also following the "top-to-bottom" locking idea.

[0169] ⑦ After completing the above steps, the write operation has already held the system write lock and transaction write lock of all tree nodes on the modified branch, thus preventing other read / write operations from accessing the branch. Finally, the write operation releases the system write lock of the branch after modifying the content of the branch, and the transaction write lock can only be released after the transaction is committed or rolled back.

[0170] The above content describes the execution process of insert and delete operations on B+ trees in concurrent scenarios. Figure 7 In the figure, Line 1-22 is the growth phase of the transaction. In this phase, the transaction can obtain the transaction read lock and the transaction write lock. The transaction read lock is allowed to be released, but the transaction write lock must be held until the transaction is committed or rolled back. This operation mode strictly follows the strict two-phase locking protocol to ensure that the lock management meets the protocol requirements during the transaction life cycle, thereby ensuring data consistency and system concurrency.

[0171] (3) Update operation;

[0172] In a concurrent scenario, the B+ tree update operation process is similar to the query operation. The specific process is as follows: Figure 8 shown.

[0173] The update operation uses the in-place update method, that is, the data is modified without changing the B+ tree structure. Compared with the query operation, the update operation has a key difference in the leaf node locking process. In the update operation, you first need to obtain 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 be kept for a longer time until the transaction is committed. Specifically, Figure 8 Line 1-18 in the figure belongs to the growth phase of the transaction. In this phase, the transaction can acquire and hold the transaction read lock or write lock, and release the transaction read lock; the subsequent part enters the reduction phase. This process strictly follows the strict two-phase locking protocol to ensure that the lock management during the transaction life cycle meets the requirements of the protocol, thereby ensuring data consistency and effectively controlling concurrency.

[0174] 3. Read committed isolation level implementation;

[0175] In the implementation of the Read Committed isolation level, the transaction read lock is released immediately after use. When a transaction reads the data of the same record again, it needs to reacquire the transaction read lock. The transaction write lock is held until the transaction is committed or rolled back. To further illustrate the basic implementation details of the Read Committed isolation level, the following will describe the four operation processes of query, insert, delete, and update of the primary index B+ tree.

[0176] (1) Query operation;

[0177] According to the Read Committed isolation level, transaction read locks are released immediately after use. This ensures that transactions do not hold locks after reading node data, allowing other transactions to read or modify data concurrently. In airborne database systems, transaction read locks are used to lock nodes to effectively avoid reading uncommitted content. The function of transaction read locks is to maintain the consistency of data reading and prevent other transactions from modifying the same node. By using transaction read locks, transactions can ensure data visibility when reading data without being interfered with by uncommitted modifications of other transactions. Figure 6 As shown, the transaction read lock of the node is first acquired (Lines 04, 08, 12) to avoid reading data that is being modified or not yet committed by other transactions, and the lock is released immediately after reading the data in the node (Lines 14, 18), which complies with the logic of the read committed isolation level.

[0178] (2) Insertion / deletion operations;

[0179] According to the requirements of the read committed isolation level, the transaction write lock will remain locked before the transaction is committed, ensuring that other transactions cannot read the uncommitted content. Only after the transaction is successfully committed will the transaction write lock be released, allowing other transactions to continue to read or modify the node. The use of transaction write locks effectively prevents other transactions from reading uncommitted data, avoids the occurrence of dirty reads, ensures data consistency and isolation, and also reduces the holding time of the system write lock, effectively reducing the overhead caused by the lock-based concurrency control mechanism, and improving the system's performance and concurrent processing capabilities.

[0180] exist Figure 7In the implementation of read committed isolation, the main difference between optimistic write operations and query operations is that the transaction write lock of the leaf node will be maintained until the transaction is committed or rolled back to prevent other transactions from reading the records modified by the current transaction. In contrast, the pessimistic write operation first uses the system write lock to lock all nodes that need to be modified, and then obtains the corresponding transaction write locks one by one. After completing the relevant modification operations, the system write locks will be released immediately, while the transaction write locks will last until the transaction is committed or rolled back (Line 23).

[0181] (3) Update operation;

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

[0183] 4. Transaction rollback implementation;

[0184] The above content describes the system's processing when the locking operation is successful. In actual applications, the system's locking mechanism follows the "top-down" locking rule, so deadlock problems usually do not occur. However, due to conflicts in access to the same data item by different transactions, transaction deadlock may occur, causing transactions of the same priority level to wait for each other; or because high-priority transactions preempt the resources of low-priority transactions, low-priority transactions need to be rolled back. To resolve such transaction conflicts, the system needs to take rollback measures to terminate one of the transactions. The specific transaction rollback process is as follows: Fig. 9 shown.

[0185] After a transaction lock deadlock occurs, the transaction lock manager triggers the deadlock detection mechanism and immediately rolls back the transaction that failed to lock. To ensure the atomicity and consistency of transactions, when any page is modified during the transaction execution, the page will be backed up to the old page set. When a transaction needs to be rolled back, the modified pages are locked by the transaction write lock, which means that other transactions cannot access these pages. Fig. 9 In the loop, all page sets locked by the transaction are visited 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 concurrent control of embedded database transactions based on Tianmai operating system, characterized in that: The steps include: Step 1: Construct system lock and transaction lock; In the onboard database, the database file is organized in pages, with B+ tree as the underlying data structure. The system lock is used to protect the physical structure security of the B+ tree under multi-threading, and the transaction lock of the lock manager is combined to implement the locking operation of data records. Step 1-1: System lock; Implement system locks based on semaphores, allowing multiple threads to read shared resources at the same time, but only allowing one thread to perform write operations at any time; Step 1-2: Transaction lock; Using two types of locks, i.e., shared locks and write locks, i.e., exclusive locks, concurrent operations are divided into four types: read-read, read-write, write-read, and write-write. At least the concurrency of read-read operations can be allowed, and the lock compatibility matrix is ​​obtained; Concurrent operations are allowed only when different transactions have read locks on the same data item. In other cases, new lock requests cannot be granted. When the same transaction locks the same data item, lock escalation may occur. A page-based locking mechanism is used to implement transaction concurrency control by locking pages. Step 2: Transaction concurrency control protocol selection; A pessimistic concurrency control protocol is adopted. All exclusive locks held by a transaction can only be released after the transaction is committed. It ensures that any data written by an uncommitted transaction is locked with an exclusive lock before the uncommitted transaction is committed to prevent other transactions from reading the 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, not write locks, and all write locks must be released after the transaction is committed or aborted. Step 3: Transaction isolation level selection; There are four transaction isolation levels: read uncommitted, read committed, repeatable read, and serializable; Use read committed isolation to allow transactions to read modifications made by other committed transactions; During transaction execution, the current transaction is not allowed to read modifications being made by other transactions; At the read committed isolation level, a transaction can only see the latest data status that has been committed by other transactions when reading data; Step 4: Transaction rollback mechanism; When a transaction modifies a data page, not only will the actual data page be updated, but the old page before the transaction modification will also be saved in memory as a shadow page of the newly modified dirty page, which is maintained using the OldPage hash table; Shadow pages are saved in memory rather than on disk. When a conflict occurs between different transactions and a transaction needs to be rolled back, since all modified pages of the transaction are locked by the transaction lock of the lock manager, the previously saved shadow pages can be used directly to overwrite the current data pages, returning the data to the consistency state before the modification.

2. The method for concurrent control of embedded database transactions based on the Tianmai operating system according to claim 1, characterized in that: The system lock is as follows: A counting variable is used to track the number of readers who have successfully acquired the read lock. During the acquisition of the read lock, only the first reader who requests the read lock will actually obtain the lock, while other subsequent readers will only increase the count and mark the current lock state as "read mode". When a write lock is requested, the system will directly call the interface to obtain the write lock, and set the current lock state to "write mode" after successful acquisition. 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; The application and release of system lock resources are centrally managed through an independent lock pool. During the database system initialization process, the system automatically initializes the lock pool and dynamically calculates the capacity of the lock pool based on the size of the cache pool. This method ensures efficient allocation and recycling of lock pool resources while avoiding the performance overhead caused by frequent lock creation and destruction.

3. The method for concurrent control of embedded database transactions based on the Tianmai operating system according to claim 2, characterized in that: The transaction lock is as follows: Design a lock manager to centrally and uniformly manage transaction locks. Under the premise of page-based locks, 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 the page number and the lock table. The lock table stores the current lock status of the page and the information of different transactions applying for locks on the page, including group mode, wait bit, number of transactions granted the current lock, and list. ① When a transaction requests a lock on page A, the lock request is not compared with the locks held by other transactions on the page one by one. The grant / reject decision is simplified by comparing only the request with the group mode; the specific rules are as follows: aS means that only read locks are held, and there may be multiple read locks; bX means there is only one write lock and no other locks; ②The wait bit indicates that at least one transaction is waiting for the lock on page A; ③The number of transactions granted the current lock; Record how many transactions have been granted the current lock in the current group mode; ④ 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: a. The transaction ID that holds or waits for a lock; b. The type of lock requested by the transaction; c. Whether the transaction holds a lock or waits for a lock; All these list items on page A are stored in the array ArrayList; 1) Lock application; Assume that transaction T requests a lock on page A. There are several situations for the lock processing between different transactions: ① 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 approved; ② If there is a lock table entry for page A, then the group mode is found. 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 this case, the entry of transaction T in the list will have "wait = No", and the write lock will be denied. An entry indicating that transaction T applied for a lock 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 entry of transaction T in the list will have "wait = Yes". The above processing for applying for locks between different transactions, for the same transaction T, if a read lock has been obtained on page A, now the lock needs to be upgraded. If the current group mode of the lock table is read lock, and there is only one read lock, then the write lock can be directly granted to transaction T, and the locking mode of transaction T in the list item is 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 in the list item is changed to write lock, and the wait bit is also changed to "wait = Yes"; 2) Release of lock; Assume that transaction T unlocks page A. The entry of transaction T on page A in the list will be deleted. If there are other entries in the list, a new group mode needs to be found based on the first-come-first-served principle. If the new group mode 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 other read locks. 3) Deadlock detection; The wait timeout mechanism is used to solve the deadlock problem.

4. The method for concurrent control of embedded database transactions based on Tianmai operating system according to claim 3 is characterized in that: The pessimistic concurrency control protocol is a strict two-phase blocking protocol, as follows: During the lock growth phase, you can acquire a read lock or a write lock. A read lock can be released immediately after use, while a write lock 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; A strict two-phase blocking protocol is described for the four operations of query, insert, delete and update of the primary index B+ tree; (1) Query operation; ① The read operation starts from the root node, first holding the system read lock of the root node, and then holding 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 conditions, then obtains the transaction read lock, and then releases the parent node transaction read lock and system read lock; ③ 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 must be added first and then a system read lock must be added, and the deadlock detection mechanism of the transaction lock manager must be used to detect and resolve the deadlock; ④ After reading the content of the leaf node, release the system read lock and transaction read lock of the leaf node; When a transaction performs a 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 transaction read lock are released immediately after use and do not need to be held until the transaction commit stage. (2) Insertion / deletion operations; ① When a write operation locks a B+ tree, an optimistic strategy is first used to set the lock to the query state; ② When reaching a leaf node, first add a transaction read lock to determine whether the node is safe, that is, whether the operation will cause the node to be split / merged or other tree structure modifications; if the node is safe, upgrade the transaction read lock to a transaction write lock, and then add a system write lock to complete the locking process; If the node is unsafe, you need to release all locks, continue with the subsequent steps, use the pessimistic strategy, and re-lock the root node; ③ Under the pessimistic strategy, the write operation also starts from the root node. First, the system write lock of the root node is held, and the locked node is added to the write lock node set of the transaction; ④ The write operation first obtains the system write lock of 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 of the ancestor node, otherwise it temporarily holds the system write lock of the parent node and adds the node to the write lock node set of the transaction. This process is repeated until a leaf node is found; ⑤ When reaching the leaf node, you need to first obtain the transaction write lock, and then obtain the system write lock; ⑥Since the transaction write lock is not obtained at the same time as the system write lock of the non-leaf node, it is necessary to add transaction write locks to all locked non-leaf nodes separately; ⑦ The write operation releases the system write lock of the branch after modifying the content of this branch. The transaction write lock can only be released after the transaction is committed or rolled back; (3) Update operation; The update operation uses an 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 obtain 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, and the transaction write lock will not be released until the transaction is committed.

5. The method for concurrent control of embedded database transactions based on Tianmai operating system according to claim 4, characterized in that: 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 data of the same record again, it needs to reacquire the transaction read lock; and the transaction write lock is held until the transaction is committed or rolled back. The four operation processes of query, insert, delete and update of the primary index B+ tree are described; (1) Query operation; According to the Read Committed isolation level, transaction read locks are released immediately after use; In the onboard database system, transaction read locks are used to lock nodes, effectively preventing the reading of uncommitted content; (2) Insertion / deletion operations; According to the requirements of the read committed isolation level, the transaction write lock will remain locked before the transaction is committed, ensuring that other transactions cannot read the uncommitted content; (3) Update operation; When reading a node inside a B+ tree, first acquire a transaction read lock, then release the lock immediately after completing the read operation; For the updated leaf node, the transaction write lock is continuously used to lock it until the lock can be released before the transaction is committed.

6. The method for concurrent control of embedded database transactions based on Tianmai operating system according to claim 5, characterized in that: The step 4 is specifically as follows: After a transaction lock deadlock occurs, the transaction lock manager triggers the deadlock detection mechanism and immediately rolls back the transaction that failed to lock. To ensure the atomicity and consistency of transactions, when any page is modified during the transaction execution, the page will be backed up to the old page set. When a transaction needs to be rolled back, the modified pages are locked by the transaction write lock; all page sets locked by the transaction are accessed one by one, and the corresponding pages are retrieved from the old page set according to the page ID to restore the currently modified pages and restore them to the state before the transaction was executed.

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

8. An electronic device, characterized in that: include: Processor and memory; The memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory, so that the electronic device executes the method as claimed in any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

10. A chip, characterized in that: include: A processor, configured to call and run a computer program from a memory, so that a device equipped with the chip executes a method as claimed in any one of claims 1 to 6.

Images