Four database isolation strategies to achieve multi-threaded control;
Design the transaction strategy of the database to realize multi-threaded processing from the perspective of things (not only java, pessimistic locks, etc.)
In fact, it is the order of reading and modification (insert another before completion), in the case of multi-threading, data problems occur
Questions are as follows:
Dirty read (read without modification)
One thing modifies the data but has not submitted the modification, another thing uses the data again
Non-repeatable read (it is modified again in the middle of multiple reads, resulting in a different result from the previous one)
A thing needs to read a data multiple times, and another thing modifies this thing in the middle, resulting in different data
Phantom reading (after reading it is changed by another thing)
The strategy is as follows:
The strategy adopted in one thing, after setting, every thing will use this strategy
For the above situations, the database proposes 4 isolation strategies (strategies adopted in one thing)
Isolation level Dirty Read NonRepeatable Read Phantom Read
===========================================================================================
Read uncommitted may be possible
Read committed Impossible Possible Possible
Repeatable read Impossible Impossible Possible
Serializable Impossible Impossible Impossible
Read Uncommitted: Allows dirty reads, that is, it is possible to read data modified by uncommitted transactions in other sessions
·Committed read (Read Committed): Only the data that has been submitted can be read. Most databases such as Oracle default to this level (non-repeatable read)
·Repeated Read: Repeated read. Queries within the same transaction are consistent at the beginning of the transaction, the default level of InnoDB. In the SQL standard, this isolation level eliminates non-repeatable reads, but there are still phantom reads
Serializable: A fully serialized read, each read requires a table-level shared lock, and reads and writes will block each other
http://www.jb51.net/article/100183.htm
http://blog.chinaunix.net/uid-24111901-id-2627894.html