What is the difference between concurrency control and transaction isolation levels?
I understand each of them clearly, however, I am having some problems relating them to each other. Specifically, I see some overlap in their functions and I’m not sure when one should use one over the other. Or should both be used together?
Also what does it mean to say pessimistic locking with repeatable read? Doesn’t repeatable read already imply that all values to be edited will be locked? So why is there still a need for pessimistic locking?
The issue arises because there are two models for concurrency control, which are sometimes mixed by SQL implementations.
Pessimistic means rows that are read are locked. Optimistic means rows that are read are not locked.
The classic 2PL implementation of Repeatable Read is always pessimistic. The multiversion implementation of Repeatable Read is optimistic. It does not lock the rows that are read for a SELECT statement and allows other transactions to modify the rows that have been read in a SELECT. Such changes are not visible to the transaction that performed the SELECT, until it is committed.