Read lock, write lock concept
Read locks are also called shared locks (denoted as S, or shared-mode lock), and write locks are also known as exclusive locks (denoted as X, or exclusive-mode lock). Each transaction must apply for an appropriate lock for the operation type of a data item.
Compatible: Read locks are compatible with read locks, that is, the same data item can be applied for read locks by multiple transactions at the same time. However, read locks are incompatible with write locks, write locks and write locks, that is, if a data item has been applied for a read lock, it can no longer be applied for a write lock.
Four isolation levels (for reading)
Regarding the handling of write locks:
write locks when writing (update adds write locks to updated rows, insert adds write locks to newly inserted rows), and puts write locks at the end of the transaction.
Regarding the handling of read locks:
Serializable : The
order of execution can only be executed in the unit of transaction (but not in the unit of statement), parallelization is the lowest, the efficiency is the worst, but the security is the highest. Dirty reads, non-repeatable reads, and phantom reads can be avoided.
Repeatable read :
add a read lock when reading, and put a read lock when the transaction ends. Dirty reads and non-repeatable reads can be avoided, but phantom reads will occur.
Read committed :
Add a read lock when reading, and release a read lock after reading. Dirty reads can be avoided, but non-repeatable reads and phantom reads will occur.
Uncommitted read read uncommitted :
No read lock is added when reading. There will be dirty reads, non-repeatable reads and phantom reads.
The four isolation levels are only for reads (select), so there is no point in declaring an isolation level for transactions that only write operations.
Dirty reads, non-repeatable reads, and phantom reads
Dirty read : uncommitted modified data has been read.
With relational model R(a, b), there is a tuple (1,2) at the beginning, and there are two transactions: T1, T2 (begin transaction and end transaction at the beginning and end are omitted):
T1:
update R set a=a*2
commit
T2：
select max(a) from T1
We don’t care about the isolation level of T1 (because T1 only performs write operations, and the isolation level is for reading).
If T2 runs at the isolation level read uncommitted, when T1 has not been submitted but has been updated, T2 will read max(a)=2, but if T1 is rolled back due to various reasons , then the database will not change. The 2 read by T2 is a "dirty data", so it is called a dirty read.
Non-repeatable read : The value obtained by repeatedly reading the same data in a transaction is different.
There are two university database transactions T1, T2: (S1, S2, S3 are statements, S1 includes commit)
T1:
S1: update student set GPA=GPA*2
commit
T2：
S2：select max(GPA) from student
S3：select max(GPA) from student
If T2 runs at the isolation level read commited , the execution order can be S2-S1-S3, because S2 adds a read lock when reading, and releases it after reading. Then S1 can add write locks to all data items, then release at the end of T1, and finally S3. Execute in this order, the result of reading is different, that is, it cannot be read repeatedly.
But if T2 runs at the isolation level repeatable read , the execution sequence cannot make S2-S1-S3, because S2 adds a read lock when reading and releases it when T2 ends, so S1 cannot get the write lock (because all data items have been Added a read lock). So repeatable read can avoid updating between two reads to make the results of reading the same value different.
Phantom reading : If there is an insert between two readings, there will be phantom tuples (phantom tuples), resulting in different results when reading the same value.
Or are the two transactions T1 and T2 of the university database:
T1:
S1: insert into [100 new tuples]
T2：
S2：select max(GPA) from student
S3：select max(GPA) from student
The execution order can be S2-S1-S3, because S2 just adds a read lock to all current items, while S1 inserts a new data item and adds a write lock. The two do not conflict, and then release the newly added 100 after T1 ends. S3 can execute the write lock of a tuple. The result is that there are 100 phantom tuples , and insert causes different results for repeated reading of the same value .
A classic example
The table sell (Bar, Beer, Price), initially sell has 2 tuples ('joe's bar, Qingdao, 20), ('jackson's bar, Guinness, 50). There are two transactions T1, T2: (S1~S4 represent statements)
T1：
S1：insert into sell values(‘joe’s bar,Heinesen,60)
S2：update sell set Price=Price+10
commit
T2：
S3：select max(Price) as p1 from sell
S4：select min(Price) as p2 from sell
Known isolation level: T1 is serializable, T2 is repeatable read, find the running result of T2.
Answer:
Don't care about the isolation level of T1, just look at T2: add a read lock when reading, and release it when the transaction ends.
S2 cannot appear between S3 and S4 , because the execution of S3 will add a read lock to all rows, and then S2 will fail to execute.
S1 cannot appear between S3 and S4 , because if S1 is between S3 and S4, S2 can only be after S4, the order is S3-S1-S4-S2, S3 adds a read lock to the original 2 rows, and S1 gives Add a new line to add write lock, S4 cannot add read lock (that is, it cannot be executed).
So the execution order can only be T1-T2 or T2-T1.