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

P_K>·>А что от чего зависит? Если у тебя заказ зависит от цены, а цена зависит от заказа — ну тут да, феерверк и бардак — как карты лягут.
P_K>Заказ в зависит от цены.
P_K>Цена в справочнике от заказов не зависит. При изменении цены мы должны обновить некоторые заказы, зависимостью это считать нельзя на мой взгляд. Это следствие первой зависимости, скорее даже метод её поддержания.
Ну да, это значит что некоторые заказы зависят от цены. Всё.

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