Database locks, transactions and locks

1. Transaction

I: Definition of Transaction:

First, let us understand what is a transaction? A transaction is a series of operations performed as a single logical unit of work. Can be a single sql statement or multiple sql statements (this is its descriptive definition).

II Transaction characteristics:

1) Atomicity (Atomic): refers to the entire database transaction is an inseparable unit of work.

2) Consistency: refers to the fact that database transactions cannot destroy the integrity of relational data and the consistency of business logic.

3) Isolation: In a concurrent environment, when different transactions operate on the same data at the same time, each transaction has its own complete data space.

4) Durability: It means that as long as the transaction ends successfully, the changes it makes to the database must be permanently saved.

The database uses the log to ensure the atomicity, consistency and durability of the transaction. The log records the updates made by the transaction to the database. If an error occurs during the execution of a transaction, it can undo what the transaction has done to the database according to the log. Changes that return the database to the initial state it was in before the transaction was executed.

The database uses a locking mechanism to ensure transaction isolation and has its own independent space.

What does it mean that a transaction has these four characteristics? Does it mean that a transaction must have these four characteristics to become a transaction or not a transaction? I think so, transactions must have three characteristics of atomicity, consistency and durability, and isolation determines the degree of isolation and isolation level according to actual needs (it is based on this that the isolation level of subsequent transactions is derived. ).

  III. Transaction isolation level

1, database transaction isolation level: four

So what does the isolation level of a transaction have to do with locks? In my opinion, the isolation level of a transaction is achieved through the lock mechanism, and the isolation level of a transaction is a set of lock usage strategies defined by the database developer according to the actual needs of the business logic. When we define the isolation level of the database to a certain level, if it still cannot meet the requirements, we can customize the sql lock to override the default lock mechanism of the transaction isolation level.

Read Uncommitted (Read Uncommitted)

This is the lowest transaction isolation level. Read transactions will not block read and write transactions, and write transactions will not block read transactions, but will block write transactions. One result of this is that when a write transaction is not committed, the read transaction can still read, resulting in the phenomenon of dirty reads.

When Read Committed

adopts this isolation level, the write transaction will block the read transaction and the write transaction, but the read transaction will not block the read transaction and the write transaction, so because the write transaction will block the read transaction, Then the read transaction cannot read the dirty data, but because the read transaction will not block other transactions, it will still cause the problem of non-

repeatable Repeatable read (Repeatable Read)

adopts this isolation level, and the read transaction will block the write. Transactions, but read transactions do not block read transactions, but write transactions block both write and read transactions. Because the read transaction blocks the write transaction, the problem of non-repeatable reads will not be caused, but the phantom read problem cannot be avoided.

Serializable

isolation level is the strictest isolation level. If it is set to this level, then all the above problems (dirty reads, non-repeatable reads, phantom reads) will not occur. But this will greatly affect the performance of our system, so we should avoid setting this isolation level.

In practice, we generally use the transaction isolation level of read committed or lower, and cooperate with various concurrent access control strategies to achieve the purpose of concurrent transaction control.

2. Lock

MySQL's InnoDB has two modes of row locks:

1) Shared locks: allow one transaction to read a row and prevent other transactions from obtaining exclusive locks on the same dataset.

    ( Select * from table_name where ......lock in share mode)

2) Exclusive lock: Allows the transaction that obtains the exclusive lock to update data, and prevents other transactions from obtaining the shared read lock and exclusive write lock of the same data set. (select * from table_name where.....for update)

     In order to allow the coexistence of row locks and table locks, a multi-granularity lock mechanism is implemented; at the same time, there are two internal intention locks (both table locks), which are intention sharing Locks and Intent Exclusive Locks.

InnoDB row locks are implemented by locking index items, that is, only by retrieving data through index conditions, InnoDB uses row-level locks, otherwise table locks are used!

3. Concurrency control

When many people try to modify the data in the database at the same time, it is necessary to implement a control system so that the modifications made by one person will not have a negative impact on others. This becomes concurrency control. There are two types of concurrency control:

Optimistic concurrency control and pessimistic concurrency control.

Optimistic concurrency control:

optimistic locking:

basic idea: every time a transaction update is submitted, we first check whether the thing to be modified has been modified since the last read, if modified, the update will fail.

Optimistic locking does not actually lock any records, so if the transaction isolation level of our database is set to read committed or lower isolation level, then the non-repeatable read problem cannot be avoided (because the read transaction will not block at this time other transactions), so when using optimistic locking, the system should tolerate the occurrence of non-repeatable read problems.

Optimistic locking implementation strategy

Version field: Add a version control field to our entity, and add 1 to the value of the version field after each transaction update.

Timestamps: After adopting this strategy, when each update is to be submitted The current time and modification time of the system will be displayed.

Pessimistic locks are what we think of as locks in the usual sense mentioned above.