Оптимистично-Блокировка абсолютно безопасна?

Question

при использовании стратегии оптимистически-блокировки, это может решить проблему параллелизма, как показано ниже:

 
| the first transaction started  | 
|          | 
| select a row       | 
|          | the second transaction started 
| update the row with version checking | 
|          | select the same row 
| commit txn       | 
|          | update the row with version checking 
|          | 
|          | rolls back because version is dirty 

Но что, если в крайне редких случаях, если обновление во второй транзакции после udpate в первой транзакции, но перед тем, сделка совершена?

 
| the first transaction started  | 
|          | the second transaction started 
| select a row       | 
|          | select the same row 
| update the row with version checking | 
|          | update the row with version checking 
| commit txn       | 
|          | rolls back because version is dirty // will it? 
|          | 
|          | 

Я сделал эксперимент, что обновление во второй транзакции не мог читать «грязной» версии, потому что первая сделка не было совершено еще. Произойдет ли в этом случае вторая транзакция?

Answer 1

Вы не сказали в своем вопросе, какую систему баз данных вы используете, поэтому я не знаю деталей вашей системы.

Но в любом случае, при оптимистичной системе блокировки, процесс не может просто проверять версии строк при выполнении оператора обновления из-за именно той проблемы, о которой вы беспокоитесь.

Для полностью сериализуемых изолированных транзакций каждый процесс должен атомарно проверять версии строк всех строк, которые он исследовал и модифицировал, в момент фиксации. Таким образом, в вашем втором сценарии правый процесс не будет обнаруживать конфликт, пока он не попытается совершить (шаг, который вы не включили для правого процесса). Когда он пытается совершить, он обнаружит конфликт и откатится.