Comments 4
PESSIMISTIC_FORCE_INREMENT => PESSIMISTIC_FORCE_INСREMENT
Показалось, что постановка проблемы не совсем ясная. Хотелось бы по подробнее, что значит - вторая транзакция перетёрла вторую? Где и что перетёрлось?
Вы про потерянное изменение? Если да, то сейчас поясню. У нас есть две транзакции T1 и T2, которые работают с одной и той же записью A в таблице. Пусть запись A содержит баланс счета и он равен 1000 руб. T1 считала A. Затем T2 считала запись A. В обоих случаях баланс равен 1000 руб., так как никаких изменений в бд еще не произошло. По сути каждая из транзакций закешировала конкретное состояние записи. В каждой из транзакций происходит какая-то бизнес логика. После выполнения T1 значение баланса A стало 800 рублей, а после T2 стало 900 руб. Так случилось, что T1 выполнилась быстрее, чем T2, и записала в бд свой результат работы. Но при этом T2 ничего не знает о произошедших изменений в таблице и просто перетирает результат выполнения T1 и пишет свой результат работы, где баланс равен 900.
Какой корректный результат? Корректно бы было сначала вычесть из баланса 200, а затем 100. Таким образом бы правильное состояние баланса было бы 700.
Вот такую проблему решают пессимистические и оптимистические блокировки.
Оптимистические и пессимистические блокировки на примере Hibernate (JPA)