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

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

P_K>Каковы будут ваши варианты решения?
P_K>Данный пример очень упрощён, на самом деле факторов много и варианты их влияния бывают самыми разными (например, наличие у клиента другого неподтверждённого заказа запрещает создавать новый).
Оптимистичная блокировка же.

Как видишь — универсального решения тут нет, делать можно что угодно как угодно — зависит только от конкретных бизнес-требований.