Database pessimistic locking and optimistic locking

Now we simply talk about database pessimistic locking and optimistic locking.

Pessimistic locking

As its name pessimistic locking, pessimistic. Always think: Whenever modify data, there will be other thread will modify the data at the same time. So for this situation pessimistic locking approach is: After reading the data is locked (eg: select...for update), so other threads to read the data when you need to wait for the current thread releases the lock, the lock to get the thread to get read and write access to the data . Thus ensuring the concurrent modification of data errors. However, due to blockage reasons, resulting in throughput is not high. Pessimistic locking is more suitable for reading and writing cases less.

Scene: Students A and B students must turn to you 500 dollars (bad fun of it, so that eventually you can get 1000 dollars).

Use pessimistic locking process:

1. A classmates to get your account balance balance = 0and the record is locked.
2. B students get your account balance. Because the students had already had an A record lock, so students and other students B needs A transfer is completed (release lock) to get the balance.
3. A transfer students to complete and release the lock, then your account balancebalance=balance + 500 = 500
4. B students get into your account balance balance = 500, and the record is locked (if your karma is good, then you transfer to the C students also need to wait for the transfer to B students can transfer oh)
5. B students to complete the transfer and release the lock (if you want to give some students transfer C, then C students can get a lock and transfer). At this time, your account balancebalance = balance + 500 = 1000
6. Eventually you happy to get 1,000 yuan.

Assuming that the transfer process does not lock, we see what happens:

1. A classmates to get your account balance balance_a = 0(not locked, then the students can also get to the B account balance)
2. B students get into your account balancebalance_b = 0
3. A classmates transfer is completed, your account balance is at this timebalance = balance_a + 500 = 500
4. B students to complete the transfer, your account balance is at this timebalance = balance_b + 500 = 500
5. A final classmates and students have switched to the B 500, but you ended up with only 500. This must not accept it.

Lost where 500 to? After the balance 500 can be seen from step 2 to obtain the students B account balance is 0, A and not transfer students. So the problem here, which is a common problem of high concurrency scenarios. So lock is very necessary. But added a pessimistic locking, transfer students have to queue up to me, impatient for the students direct debit is not, I would not miss a good opportunity to make a fortune. So what better way to do it? The answer is the following optimistic locking

Optimistic locking

Optimistic locking the name suggests more optimistic, he is only updated when the data will check whether this data is updated by another thread (this is the same as with pessimistic locking, pessimistic locking is the time to read the data on the lock). If you update the data and found that this data updated by another thread, then the update fails. If the data is not used by another thread updates, the update was successful. Since the optimistic lock is not waiting for the lock to improve throughput, so read less optimistic locking for multi-write scenes.

Common implementations are optimistic locking: version version and CAS (compare and swap). So only the version number of ways.

To adopt the version number, you first need to add a field in a database table version, represents an updated version of this record, record every change of time, the version number is incremented. Transfer still use the above examples:

1. A classmates to get your account balance balance = 0and version numberversion_a = 0
2. B students get into your account balance balance = 0and version numberversion_b = 0
3. A complete transfer students update table set balance = ${balance}, version = version + 1 and version = 0. (At this version number is 0, so the update is successful)
4. B students to complete the transfer update table set balance = ${balance}, version = version + 1 and version = 0. (At this time, the version number is 1, the update fails, after the failure to update the students once sub B)
5. After the re-transfer students B, you still get flattered 1000.

to sum up

Pessimistic Lock: read lock, complete updated release the lock, then this process will result in the other thread is blocked, resulting in lower throughput for write scenarios.

Optimistic lock: no lock, only to verify whether the data is updated in the other thread update, higher throughput for read more scenes.