Re[9]: Блокировки в бизнес-слое
От: · Великобритания  
Дата: 27.09.17 16:09
Оценка:
Здравствуйте, 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.

Т.е. по сути у тебя тут распределённая система из двух компонент — клиент и сервер — они и должны согласовываться.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.