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

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

Q>>Классическим примером тут является Order и OrderItem. При правке OrderItem блокируется Order и все его OderItem. Блокировка может быть как оптимистической так и пессимистической.

P_K>Вот это по-моему как раз не то. Это один агрегат. Агрегат есть единица обеспечения целостности и поэтому он всегда должен обрабатываться целиком, в том числе блокироваться тем или иным способом.
P_K>Я же говорю о другом.
P_K>Например, вы создаёте заказ. Заказ для клиента, у клиента есть какой-то свой процент скидки, и соответственно в заказе вы должны на все позиции проставить эту скидку.
P_K>Сам по себе клиент не является частью агрегата заказа. Но на время операции создания заказа мы должны обеспечить неизменность процента скидки клиента. Иначе есть риск создать заказ со скидкой, которая уже не действительна (была изменена параллельно с созданием заказа).
P_K>Вопрос в том как обеспечить эту неизменность. Возьмём решение посредством блокировок. Объектом блокировки у нас будет клиент. То есть, на время создания заказа блокируем клиента, для которого создаётся заказ.

P_K>Теперь разовьём тему. Стоимость строки заказа складывается из цены и скидки клиента. Со скидкой разобрались, цены же берутся из прайс-листа. Значит на время создания заказа нужно блокировать ещё и прайс-лист (целиком — в этом смысл подхода "крупногранулярные блокировки").

P_K>В реальности получится что на время создания заказа нужно будет блокировать кучу разных вещей, и не исключено необходимость блокировки некоторых станет ясна только в процессе. Это значит что могут возникать взаимоблокировки, что усложняет решение...

P_K>Так что с фразой "Там ни чего сложного" я бы поспорил

Проблемы конкурентного доступа это естественная проблема доступа к данным. Пользователь (заказчик) должен озвучить, как ваша программа в таких случаях должна работать. Изолированность бизнес-транзакций являются частью т.з. на вашу программу. А так размышлять об абстрактных случаях — пустое дело.

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

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

Q>>Классическим примером тут является Order и OrderItem. При правке OrderItem блокируется Order и все его OderItem. Блокировка может быть как оптимистической так и пессимистической.

P_K>Вот это по-моему как раз не то. Это один агрегат. Агрегат есть единица обеспечения целостности и поэтому он всегда должен обрабатываться целиком, в том числе блокироваться тем или иным способом.
P_K>Я же говорю о другом.
P_K>Например, вы создаёте заказ. Заказ для клиента, у клиента есть какой-то свой процент скидки, и соответственно в заказе вы должны на все позиции проставить эту скидку.
P_K>Сам по себе клиент не является частью агрегата заказа. Но на время операции создания заказа мы должны обеспечить неизменность процента скидки клиента. Иначе есть риск создать заказ со скидкой, которая уже не действительна (была изменена параллельно с созданием заказа).
P_K>Вопрос в том как обеспечить эту неизменность. Возьмём решение посредством блокировок. Объектом блокировки у нас будет клиент. То есть, на время создания заказа блокируем клиента, для которого создаётся заказ.

P_K>Теперь разовьём тему. Стоимость строки заказа складывается из цены и скидки клиента. Со скидкой разобрались, цены же берутся из прайс-листа. Значит на время создания заказа нужно блокировать ещё и прайс-лист (целиком — в этом смысл подхода "крупногранулярные блокировки").

P_K>В реальности получится что на время создания заказа нужно будет блокировать кучу разных вещей, и не исключено необходимость блокировки некоторых станет ясна только в процессе. Это значит что могут возникать взаимоблокировки, что усложняет решение...

P_K>Так что с фразой "Там ни чего сложного" я бы поспорил

Проблемы конкурентного доступа это естественная проблема доступа к данным. Пользователь (заказчик) должен озвучить, как ваша программа в таких случаях должна работать. Изолированность бизнес-транзакций являются частью т.з. на вашу программу. А так размышлять об абстрактных вещах — пустое дело.