Здравствуйте, ·, Вы писали:

P_K>>На примере, мы показываем пользователю что заказ будет с ценой такой-то, он жмёт кнопку "Создать заказ", данные уходят на сервер, там проверятся соответствует ли цена в справочнике той, которая была на экране — это и есть оптимистичная блокировка. Цена не соответствует — показываем ошибку "Цена поменялась". Цена соответствует — создаём заказ. И в это время цена в справочнике меняется. Заказ создаётся со старой ценой в своей транзакции, цена в справочнике меняется в своей. В итоге бизнес-правило нарушено.
·>Это же транзакция — должно быть понятие точки коммита, которая даёт OK или FAIL. Мы не "создаём" заказ (что это вообще конкретно значит?), а _атомарно_ коммитим его — с подтвержёнными на момент коммита ценами. Если коммит провалился (цены поменялись до), то транзакция фейлится и, при желании, идёт на второй круг, до тех пор, пока не даст OK.
Не представляю как это должно выглядеть.
Алгоритм создания заказа:
1. начать транзакцию
2. найти клиента
3. найти товар
4. создать и сохранить сущность заказа
5. commit
Между 4 и 5 опять бежим в справочник и проверяем что цена не изменилась? Это ничего не изменит! Всё равно после этой проверки и до commit она может поменяться.

·> Любые последующие изменения цены "официально" считаются, что произошли после, а значит не должны влиять на заказ.
Категорически нет. Смотрите выше — изменение цены после приводит к пересчёту неподтверждённых заказов!