Problems in the concurrency of things, as well as pessimistic locks and optimistic locking problems

problems that occur in the concurrency of things

A) dirty reads (Dirty read), read UNCOMMITTED data.

No committed data was read for another transaction

b) Non-repeatable read (Nonrepeatable Read)

In the same thing, it is different to read 2 times before and after. (There may be a read process in which another transaction modifies the data)

c) Phantom Read (Phantom Read)

In the course of your reading, another transaction inserts a new data into it, affecting the results you read.

Insert and delete operations (here The general database locks are not allowed to be updated, deleted and inserted when possible)

Java.sql.connection has the same level of isolation and hibernate as the business.

A) read-uncommitted: capable of reading uncommitted data 3 will appear

b) read-committed: You can't limit the repetition read

c) repeateable read: The underlying is the locking mechanism.

d) Serializable: No matter how many transactions come, you give me one of the execution, there will be problems. There must be no more.

pessimistic lock, optimistic locking mechanism

In order to consider the efficiency of concurrency, we set it to read committed, but what I need to solve is non-repeatable read, in Hibernate there are two ways to solve

Pessimistic lock

AccountA = (account) session.load (Account.class, 1, Lookmode. upgrade);//upgrade

select* from ... for update

The underlying use of the database lock mechanism (only after I read the other to be able to update)

optimistic Lock

Version of the mechanism, it does not lock, with a version field. The table field adds itself, and then the update is hibernate-updated.

The corresponding table

Isolation level	Dirty Reads (Dirty read)	Non-repeatable read (Nonrepeatable Read)	Phantom Read (Phantom Read)
Unread (Read UNCOMMITTED)	possible	possible	possible
Read submitted (committed)	No way	possible	possible
REPEATABLE READ (Repeatable Read)	No way	No way	may be
Serializable (Serializable)	No way	No way	No way

This is a problem that occurs when a transaction is not supported. Generally do not need to consider