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

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

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

·>Но обычно же цена товара устанавливается независимо...
Опять же, давайте не будем углубляться в конкретный смысл, пример искусственный.

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