Chapter II Affairs

1 Concurrency and isolation

1.1 Transaction ISOLATION Level

1.2 Pessimistic lock with optimistic lock

1.3 Multi-version concurrency control

At present, most optimistic locks are basically implemented in version, and multi-version concurrency control (multi-version Concurrent controls) is a mature optimistic lock implementation.

1.3.1 Principle

MVCC is an effective means to realize transaction isolation under concurrent conditions. The essence is snapshot reads: Each tuple maintains multiple versions of the snapshot, and each transaction sees only the tuples that were committed before the transaction was inserted or modified. This avoids read-read conflicts and read-write conflicts, which greatly increase the concurrency level.

There are two cases of the so-called "before":

(1) Before the current command of the transaction. Actually corresponds to the isolation level of Read Committed.

(2) before the transaction begins. Actually corresponds to the isolation level of serialization.

The MVCC handles concurrency conflicts as follows:

(1) Read

(2) reading and writing

(3) Write and read

(4) Write

Serialization implemented by MVCC is not serialized in absolute sense. The difference between MVCC and predicate constraints is that MVCC restricts the range of reads, and predicate constraints restrict the range of writes.

1.3.2 Implementation

1.4 Lock

1.4.1 need to lock the scene

After using MVCC for isolation, the lock usage scene is greatly reduced. But the lock is still necessary. In the MVCC environment, the scenarios that require locks are:

(1) Under the multi-layer structure, the parent node is required to do the lock protection when the child node is written.

(2)

1.4.2 Sharing/Exclusive lock

1.4.2.1

1.4.2.2 Shared Lock Upgrade

Read locks can be upgraded to write locks, equivalent to read committed. Read locks are not upgradeable to write locks, and are equivalent to repeatable reads.

1.4.3 Intent Lock

Why should 1.4.3.1 have an intent lock?

1.4.3.2 Intent Lock type

(1) To add a shared lock to a child element, the parent object is first added to the intent shared lock (IS).

(2) to add an exclusive lock to a child element, it first adds an intent exclusive lock (IX) to its parent object.

For non-leaf elements, the following 4 types of intent locks are theoretically available:

(3) The element is also shared with the intent shared lock (SIS).

(4) The element also shares the lock with intent exclusive lock (SIX).

(5) The element is combined with an exclusive lock and an intent shared lock (XIS).

(6) The element is combined with an exclusive lock and an intent exclusive lock (XIX).

However, it can be seen from the intensity: Sis=s, xis=x, Xix=x, only six has a new strength. So there are actually only three types of intent locks: is, IX, six

Generalized implementation of 1.4.4 partial sequence lock

1.4.5 Lock Management

1.4.5.1 Two stage lock

1.4.5.2 Deadlock detection and processing

2 Atoms and persistence

2.1 Undo Log

The atomicity of a transaction is generally implemented by undoing the log (undo log).

2.2 Redo Log

The persistence of a transaction is implemented by the Redo log (redo log). The reason for writing redo log instead of swiping data directly to disk is. The log is written in addition, and the speed is much faster than the random write of the data.

2.3 Undo/Redo Log

2.3.1 Specific Form

2.3.2 Undo/Redo Log Implementation

2.4 Log Merge Tree

3 Transaction Execution Process

Chapter II Affairs