Implement Transaction Management in simpledb (1)

In a relational database, each operation must be completed in a transaction. From the top down, the transaction is at the top level. The transaction leads the query, the log, and the storage.

According to the idea similar to the fountain model in software engineering, the expansion of the relational database management system from small to large components is viewed in iterative mode, and the non-semantic byte storage is initially solved, then append the underlying implementation of the log, and add the transaction (including the semantic information processing of the log) to get a minimum system. Subsequent queries and optimizations can be enriched on the basis of this minimal system.

Figure 1 Minimum System

In simpledb, a small teaching database management system, there are two main components: concurrency management and recovery management. In fact, there should be a lock management. It is only implemented using a locktable.

First, let's look at the class diagram of transaction.

Figure 2 transaction class diagram

1. Concurrency Management

Each transaction has its own concurrency Manager. The concurrency manager tracks the locks held by the current transaction and exchanges information with the global lock table when necessary. It can be seen that in the concurrent management of simpledb, the core is the lock table. Through the operation of the lock table data, the concurrent management is realized.

> Locktable

The lock table provides an interface to lock and unlock blocks. The granularity is the underlying data block.

The lock table maintains a <block, int> dictionary. When dealing with access block conflicts, a busy wait mechanism is implemented: A waiting queue is maintained on each block. When a transaction requests a data block and locks it, if there is a conflict with an existing lock, the transaction is added to the waiting queue. However, all blocks share a waiting queue. At the same time, the int value of the block in the field records the number of transactions waiting on the block.

After the last lock on blockc is released, wait for all related transactions in the queue to be released at the same time and reschedule. Then, the transaction that failed the request was re-queued.

Figure 3 lock table

Tx1, tx2, tx3, and tx4 request xlock and wait for the previous slock release. tx5 requests xlock and waits for the previous xlock release.

The information on the block is saved through the dictionary. The transaction wait queue is implemented through the thread Wait Mechanism of the operating system, and no data structure is displayed.

Simpledb supports two types of locks: Shared lock slock and mutex lock xlock. Slock is represented by an increasing int value in the dictionary. xlock is represented by an int value in the dictionary-1.

The system implements the "Read-First" locking mechanism as follows:CodeAs shown in:

Figure 4 lock code

The Code shows that when slock is applied, as long as the lock currently held is not xlock, you can continue to apply the lock and directly access the block. When xlock is applied, as long as there is a lock, you have to wait. If an xlock and slock compete at the same time, it is clear that slock will always get the lock, and slock will always wait.

In order to avoid the occurrence of hunger, the lock control is added: If the wait time exceeds the threshold, the transaction throws an exception and exits.

When unlocking, if it is slock, the mark value corresponding to the block in the dictionary is directly reduced by 1; if it is xlock, the block is deleted from the dictionary, and then all the pending transactions are awakened.

> Concurrencymgr

Mark a global locktable with static. All transactions share this locktable.

An additional locks dictionary, <block, string>, and string value can be s or X, marking whether the block is added with slock or xlock.

When locking, in addition to calling the locktable interface, the <block, string> pair is saved to locks, marking s or X. Note that when xlock is added, the lock upgrade policy is used: First price slock, and then upgrade slock to xlock.

In addition, the lock here does not consider the lock wait, and the details are put in the locktable.

Figure 5 locking in concurrencymgr

Assume that the initial locks is null. First, T1 applied for slock for block1 and added <block1, S> to locks. Then, T2 applied for slock for block1. Obviously, the BLK in locks already contains the key, failed to judge the condition and did not do anything. However, it is clear that T2 is successfully locked.

If T3 needs to add xlock to block2, first determine whether there is xlock: "locks. containskey (BLK )? Locks [BLK]. Equals ("X"): false; "; in fact, both the xlock on block2 and the slock on block2 are considered.

Then add slock and xlock.

1) The field is added to locks in the phase when slock is added. At the same time, the field is added to locktbl. during the execution of slock, because no locks are available on block2 in advance, slock will be obtained directly in locktbl. the only thing that slock does is to add the value corresponding to block2 in locktbl's dictionary locks to 1, 0 --> 1.

2) Lock upgrade: After slock is applied to block2, there is actually no waiting queue on block2. Locktbl. xlock can be executed directly. Note: The condition for determining hasotherslocks is vlaue> 1 ,. The previous slock value is 1. Therefore, the hasotherslock condition is not true. Execute "locks [BLK] =-1;" directly ;". In this way, the lock is successfully upgraded.

Figure 6 locking concurrencymgr

As mentioned above, the implementation principle of concurrency Management in simpledb is implemented through locking. The maintained lock table effectively manages concurrent execution of multiple transactions.

Resume management.