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

·>... часть разработки.
Ну, ок
·>Что за смешанный статус? Есть "начали резервацию", "закончили резервацию".
А что у нас между первым и вторым? Когда половина позиций зарезервирована, а половина — нет.
Оплату мы тоже берём по частям?

·>Не понятно тогда зачем тебе именно надо в данной задаче объединять операции в одну ACID-группу. Из обоснований я пока заметил лишь: "SQL прекрасен батч-операциями".
Прекрасность SQL играет тогда, когда мы приняли решение объединять операции. Во время обработки этой ACID-группы нам противопоказаны любые коммуникации, т.к. они ведут к неограниченным задержкам.

·>Мы вроде рассматриваем вариант "просто добавляется ещё один предикат во where". Неудача и откат тут будет лишь в случае системной ошибки.
Да, это способ развернуть задачу задом наперёд — когда мы, к примеру, резервируем за одно обращение группу позиций по одному и тому же товару для ряда заказов.

S>>Увеличиваем латентность, уменьшаем throughput.
·>Почему уменьшаем?? Для мелких ордеров throughput увеличится засчёт уменьшения числа раундтрипов.
За счёт накладных расходов на "переоркестрацию" заказов.

·>Ах, вспомнил. Ты же говорил — workflow, который у тебя уже есть всё равно. Вот его и достаточно. Машина состояний, реагирует на сообщения, меняет внутреннее состояние, посылает сообщения.
Набор гарантий для такой машины очень небольшой. Доказать, что в такой системе любой заказ рано или поздно станет либо "отказанным", либо "зарезервированным" — то ещё упражнение.
Даже если отказаться от гарантий liveness и сосредоточиться на safety — что мы никогда не получим дедлок — это представляет собой крайне сложную задачу, для которой нет общего решения.

S>>Ну так как только мы перестаём "ограничиваться", так сразу теряем всю привычную REST-семантику с её гарантиями.
·>"привычную" — ключевое слово.
Именно.

·>Трейдинг он разный..
Ну, когда в руках молоток — всё кажется гвоздями. И это, к сожалению, работает для любого подхода.
Когда в руках reader_writer_lock, то кажется, что невозможно обойтись без захвата/отпускания N*M блокировок, где N — количество позиций заказов в системе, а M — количество стадий конвеера обработки заказа.
Когда в руках — LMAX Disruptor, то кажется, что любую деятельность можно представить как цепочку очередей событий.
И гарантии, которые в одном подходе легко и элегантно обеспечиваются "по построению", в другом подходе представляют собой нетривиально доказываемую (если вообще доказуемую) теорему.
И, соответственно, наоборот.