What is the optimistic locking, pessimistic locking
As the name suggests, is optimistic for what the transaction is a good one to go into development.
For pessimism is what transactions are to go bad on the one hand want to develop.
And both have advantages and disadvantages.
Pessimistic locking
A time to a shared resource threads, other threads blocking, then run out after the transfer of resources to other threads.
Every time to get the data of others will think modified, so that each time the data is going to be locked, so people then want to take this time will produce data block until it got the lock. The traditional relational database which will use a lot of this locking mechanism, such as row locks, table locks, etc., read lock, write lock is locked before doing the first operation.
Optimistic locking
Suitable for the type of application to read, you can improve throughput, similar to write_condition optimistic locking mechanism provided to the database is provided. The key: to improve throughput.
Always assume the best case, every time the data are to pick up other people think is not modified, it will not be locked, but when the update will determine what others during this time did not go to update the data, you can use the version CAS No. mechanisms and algorithms.
Other kinds of locks usage scenarios
From the above describes two locks, we know that other kinds of locks have advantages and disadvantages, can not be considered to be a good alternative, as optimistic locking apply to lower write relatively few cases (read more scene), that is true conflict when rarely happens, so we can save a lock of overhead, increase the overall throughput of the system. But if the case is to write, usually it will often produce conflict, which leads to the upper application will continue to be retry, such but rather reduces the performance, so it is more appropriate to use pessimistic locking in general to write scenes.