Transaction isolation mechanism _ pessimistic lock _ optimistic lock, transaction isolation mechanism

Transaction isolation mechanism _ pessimistic lock _ optimistic lock, transaction isolation mechanism

5. Concurrent Transaction Processing
A) features of transactions: ACID
I. Atomicity
Ii. Consistency
Iii. Isolation
Iiii. Durability persistence
B) problems that may occur during transaction concurrency
I. Category 1 Lost Update)

Time	Withdrawal transaction	Deposit transaction B
T1	Start transaction
T2		Start transaction
T3	The account balance is USD 1000.
T4		The account balance is USD 1000.
T5		Remit 100 yuan to change the balance to 1100 yuan
T6		Commit transactions
T7	Retrieve 100 yuan and change the balance to 900 yuan
T8	Cancel transaction
T9	The balance is restored to 1000 RMB (lost updates)

 

 

 

 

 

 

 

 

 

Ii. Dirty Read (Dirty Read)

Time	Withdrawal transaction	Transfer transaction B
T1	Start transaction
T2		Start transaction
T3		The account balance is USD 1000.
T4		Remit 100 yuan to change the balance to 1100 yuan
T5	The account balance for query is 1100 RMB (dirty data READING)
T6		Rollback
T7	Withdrawal 1100
T8	Transaction submission failed

 

 

 

 

 

 

 

 

Iii. non-repeatable read)

The results of two reads before and after a transaction are inconsistent, resulting in non-repeated reads, which may lead to inconsistent analysis.

Time	Withdrawal transaction	Transfer transaction B
T1	Start transaction
T2		Start transaction
T3	The account balance is USD 1000.
T4		Remit 100 yuan to change the balance to 1100 yuan
T5		Commit transactions
T6	The account balance is USD 1100.
T7	Commit transactions

 

 

 

 

 

 

Iiii. second Type of Missing update-special circumstances that cannot be read repeatedly (second lost update problem)

Time	Transfer transaction	Withdrawal transaction B
T1		Start transaction
T2	Start transaction
T3		The account balance is USD 1000.
T4	The account balance is USD 1000.
T5		Retrieve 100 yuan and change the balance to 900 yuan
T6		Commit transactions
T7	Import 100 RMB
T8	Commit transactions
T9	Change the balance to 1100 RMB (lost updates)

 

 

 

 

 

 

 

 

 

V. phantom read)

Time	Querying student affairs	Insert new student transaction B
T1	Start transaction
T2		Start transaction
T3	Query 10 students
T4		Insert a new student
T5	Query 11 students
T6		Commit transactions
T7	Commit transactions

 

 

 

 

 

 

C) database transaction isolation mechanism
I. view the java. SQL. Connection document
Ii.
(1: read-uncommitted
2: read-committed
4: repeatable read
8: serializable)
1. As long as the database supports transactions, the first type of loss update may not occur.
2. read-uncommitted: dirty read, phantom-read, and non-repeatable read may occur.
3. read-commited will not show dirty read. Because only one transaction commit will read the result, but non-repeatable and phantom-read will still appear.
4. repeatable read

D) set the transaction isolation level of hibernate
I. hibernate. cfg. xml configuration file: hiberante. connection. isolation = 2
Ii. Use pessimistic locks to solve the repeatable read problem (dependent on Database locks)
1. select... for update
2. load (xx. class, I, LockMode. Upgrade ),

A) LockMode. NONE: lockless mechanism. Switch to this mode when Transaction ends.

B) LockMode. READ hibernate automatically acquires the lock during query.

C) LockMode. WRITE insert update hibernate or automatically obtain the lock

D) The above three lock modes are used internally by hibernate.

E) LockMode. The Locks supported by UPGRADE_NOWAIT Oracle

As follows:

1 @ Test 2 public void testPessimisticLock () {3 Session session = sf. getCurrentSession (); 4 session. beginTransaction (); 5 6 Account a = (Account) session. load (Account. class, 1, LockMode. UPGRADE); // generally, UPGRADE 7 int balance =. getBalance (); 8 // do some caculations 9 balance-= 10; 10. setBalance (balance); 11 12 session. getTransaction (). commit (); 13}

 

E) Optimistic Locking of Hibernate (JPA) (ReadCommitted)

 1 package com.bjsxt.hibernate; 2  3 import javax.persistence.Entity; 4 import javax.persistence.GeneratedValue; 5 import javax.persistence.Id; 6  7 @Entity 8 public class Account { 9     10     private Integer id;11     12     private int balance;13 14     @Id15     @GeneratedValue16     public Integer getId() {17         return id;18     }19 20     public void setId(Integer id) {21         this.id = id;22     }23 24     public int getBalance() {25         return balance;26     }27 28     public void setBalance(int balance) {29         this.balance = balance;30     }31     32 }

 

Save:

1 @ Test 2 public void testOptimisticLock () {3 Session session = sf. openSession (); 4 Session session2 = sf. openSession (); 5 6 session. beginTransaction (); 7 Account a1 = (Account) session. load (Account. class, 2); 8 9 session2.beginTransaction (); 10 Account a2 = (Account) session2.load (Account. class, 2); 11 12 a1.setBalance (900); 13 a2.setBalance (1100); 14 15 session. getTransaction (). commit (); 16 System. out. println (a1.getVersion (); 17 18 session2.getTransaction (). commit (); // The version field will be compared during the second commit. If the value changes, the transaction fails to be processed and 19 systems will be rolled back. out. println (a2.getVersion (); 20 21 session. close (); 22 session2.close (); 23}

 

Jar package link: https://pan.baidu.com/s/1qYHdnbA password: p429

Pessimistic lock code link: https://pan.baidu.com/s/1o8Llad0 password: 1x2x

Optimistic lock code link: https://pan.baidu.com/s/1c1DhHtu password: ed4p