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