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

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

S>·>А зачем мы приняли такое решение?
S>Затем, чтобы обеспечить инварианты, принятые в бизнес-домене.
Давай конкретно. Вот у тебя там был процесс из 11 пунктов. Что конкретно не будет обеспечиваться, если мы резервацию будем делать построчно?

S>·>Именно. Когда мы не принимаем такие решения на пустом месте, у нас появляется свобода выбора и простор для различных оптимизаций.
S>Простор для оптимизаций появляется обычно там, где есть хорошо обоснованная эквивалентность. Вот, в частности, именно за это полюбили реляционную алгебру — она даёт дешёвую возможность строго доказать эквивалентность различных планов запросов, что и открывает простор оптимизациям, недостижимым для альтернативных моделей.
Неясно эквивалентность чего к чему подразумеваешь в контексте этого обсуждения.

S>·>Эти накладные расходы не требуют сетевых операций или блокировок. А значит практически нулевые, наносекундного диапазона.
S>Вообще-то требуют, т.к. нам нужно обеспечить какие-то простейшие вещи — например, что кто-то не пытается изменить состав заказа одновременно с тем, как отрабатывает наш код резервирования.
В твоём решении с одной транзакцией это тоже надо делать. Впрочем, это делается просто — изменять состав заказа можно только в определённых статусах заказа. Если статус "резервируется" — менять нельзя, ни в моём случае, ни в твоём. Та же песня.

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

S>·>Почему? Чем это будет отличаться от того, что ты там выше по пунктам расписывал?
S>Потому что один процесс у вас копает ямы, другой — закапывает. А тот, который должен был сажать деревья, сообщение не получил. Каждый процесс пашет в соответствии со своим ТЗ, и все юнит-тесты проходят, а результата нет.
По ТЗ процесс закапывающий ямы получает сообщения от процесса-сажателя. С какого бодуна закапыватель чего-то начнёт делать до отсылки сообщения ему?

S>·>Как раз не молоток. "Это другое". Если вспомнить историю, то этот подход популяризировался на базе Mechanical Sympathy. То есть не построили красивую абстрактность из мира идей того что "нам привычно" и пошли размахивать как молотком, мол, все наши пользователи пойдут в один сервер, или пусть идут нафик. Вот и HTTP, REST у нас, а потом совершенно ВНЕЗАПНО появились Keep Alive, pipelining, WebSocket, QUIC.
S>·>А Mechanical Sympathy — это как раз шаг к тому, как реально работают реальные системы в физическом мире. Потому это и есть дорога к сабж.
S>Всякий раз, как я вижу упоминание "как реально работают реальные системы в реальном мире", я чую булшит. Это и про ООП говорили, и даже немножко про фп.
Говорили то, что говоришь и ты: "можно представить". Тут ведь как... можно представить, а ведь можно и не представить!
Взаимодействие в физическом мире происходит посредством посылки сигналов-сообщений. Открой учебник по ТО — там будут signals-events. Произошло событие — полетел фотон. Долетел куда-то — произошло новое событие, фотоны поглотились, излучились новые.

S>Нам не особо нужно моделировать физический мир. Нам нужно моделировать решение задачи И какой формализм выбрать — state propagation или communicating automata — зависит от того, какие конкретно цели мы преследуем.
Вот только по проводу у тебя пойдёт сигнал, а не состояние. Тебе придётся построить кривенькую модель организации передачи состояния посредством сигналов. И удивиться потом, чегой-то оно тормозит и состояния постоянно разъезжаются...

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

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

S>·>А зачем мы приняли такое решение?
S>Затем, чтобы обеспечить инварианты, принятые в бизнес-домене.
Давай конкретно. Вот у тебя там был процесс из 11 пунктов. Что конкретно не будет обеспечиваться, если мы резервацию будем делать построчно?
Вот там у тебя было: "Конкретный SQL тут не так важен — важна его атомарность. Если мы всё же довели транзакцию до конца и получили в сервисе А положительный ответ от СУБД". С этим я не спорю. Я лишь уточнил, что тебе важна атомарность изменения одной строки stock и соответствующей ей строки reservationItems. Но нам не важна атомарность между всеми позициями заказа.

S>·>Именно. Когда мы не принимаем такие решения на пустом месте, у нас появляется свобода выбора и простор для различных оптимизаций.
S>Простор для оптимизаций появляется обычно там, где есть хорошо обоснованная эквивалентность. Вот, в частности, именно за это полюбили реляционную алгебру — она даёт дешёвую возможность строго доказать эквивалентность различных планов запросов, что и открывает простор оптимизациям, недостижимым для альтернативных моделей.
Неясно эквивалентность чего к чему подразумеваешь в контексте этого обсуждения.

S>·>Эти накладные расходы не требуют сетевых операций или блокировок. А значит практически нулевые, наносекундного диапазона.
S>Вообще-то требуют, т.к. нам нужно обеспечить какие-то простейшие вещи — например, что кто-то не пытается изменить состав заказа одновременно с тем, как отрабатывает наш код резервирования.
В твоём решении с одной транзакцией это тоже надо делать. Впрочем, это делается просто — изменять состав заказа можно только в определённых статусах заказа. Если статус "резервируется" — менять нельзя, ни в моём случае, ни в твоём. Та же песня.

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

S>·>Почему? Чем это будет отличаться от того, что ты там выше по пунктам расписывал?
S>Потому что один процесс у вас копает ямы, другой — закапывает. А тот, который должен был сажать деревья, сообщение не получил. Каждый процесс пашет в соответствии со своим ТЗ, и все юнит-тесты проходят, а результата нет.
По ТЗ процесс закапывающий ямы получает сообщения от процесса-сажателя. С какого бодуна закапыватель чего-то начнёт делать до отсылки сообщения ему?

S>·>Как раз не молоток. "Это другое". Если вспомнить историю, то этот подход популяризировался на базе Mechanical Sympathy. То есть не построили красивую абстрактность из мира идей того что "нам привычно" и пошли размахивать как молотком, мол, все наши пользователи пойдут в один сервер, или пусть идут нафик. Вот и HTTP, REST у нас, а потом совершенно ВНЕЗАПНО появились Keep Alive, pipelining, WebSocket, QUIC.
S>·>А Mechanical Sympathy — это как раз шаг к тому, как реально работают реальные системы в физическом мире. Потому это и есть дорога к сабж.
S>Всякий раз, как я вижу упоминание "как реально работают реальные системы в реальном мире", я чую булшит. Это и про ООП говорили, и даже немножко про фп.
Говорили то, что говоришь и ты: "можно представить". Тут ведь как... можно представить, а ведь можно и не представить!
Взаимодействие в физическом мире происходит посредством посылки сигналов-сообщений. Открой учебник по ТО — там будут signals-events. Произошло событие — полетел фотон. Долетел куда-то — произошло новое событие, фотоны поглотились, излучились новые.

S>Нам не особо нужно моделировать физический мир. Нам нужно моделировать решение задачи И какой формализм выбрать — state propagation или communicating automata — зависит от того, какие конкретно цели мы преследуем.
Вот только по проводу у тебя пойдёт сигнал, а не состояние. Тебе придётся построить кривенькую модель организации передачи состояния посредством сигналов. И удивиться потом, чегой-то оно тормозит и состояния постоянно разъезжаются...