Mosquito 132 content for their own reasoning cognitive + network __ Database

Original: Mosquito 132 content for their own reasoning cognitive + network

Mosquito 132 content for their own reasoning cognitive + network, Mosquito 132 If there are errors and unreasonable place, please point out.
in a multithreaded environment I use a thread lock to handle concurrency problems, while in a database system, concurrency problems can be refined to a transaction level, and the DBMS's approach to this is to use locks.
in order to adapt to different requirements, the perfect DBMS for the lock granularity division should be fine-grained, such as row locks, page locks, table locks, database locks. The behavior of the
locked data object is certainly different from that of the data object that is not locked, and some locks can indicate that the locked data is read-only, not modifiable, for other transactions, and that some locks indicate that the locked data data is not readable or writable for other transactions.
How to use locks. The DBMS provides keywords that we can use directly on SQL statements, such as Holdlock, Tablockx in MSSQL, and keywords that are better suited to business with special needs because we can't annotate a lot of SQL statements with keywords. So the DBMS provides us with another way--the transaction isolation level, I believe you often hear this term, but the actual project is not much, because most of the business system uses the same isolation level, we simply in the encapsulated database access layer to write dead or configured in the configuration file.

for the transaction isolation level, most databases follow a uniform standard, with four isolation levels defined in the Ansi/iso SQL92 standard:
1, serialization (SERIALIZABLE): Highest isolation level, also called serialization, as the name implies, the transaction into the execution queue, Must be executed sequentially and cannot be executed concurrently.
2: Repeatable READ (REPEATABLE READ): Uncommitted reads (dirty reads) and non-repeatable reads are not allowed (the same result is identical to the same data at any time in the same transaction)
3: Committed read (Read Committed): No uncommitted reads (dirty reads) are allowed, But allow non-repeatable reads
4: Uncommitted reads (READ UNCOMMITTED): Allow dirty reads, that is, the current transaction can obtain uncommitted changes to other transactions.
The large DBMS are slightly different in implementation.
The granularity/isolation level and concurrency/data consistency of a lock are like the following:

 
for the simple reason that concurrent transactions are blocked because of lock mutexes, the details should be understandable.
The scope of the isolation level is the session level, which corresponds to the same connection object in the program, the default isolation level for most DBMS is committed read (read Committed), and the SQL keyword has a higher lock priority than the transaction isolation level.