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

G>·>Это типичная ошибка "как дОлжно" vs "как оно физически работает". Ты описываешь идеальный мир с единорогами. Всё так, так и должно работать, спору нет, я тоже за всё хорошее и против всего плохого.
G>·>А потом внезапно получается, что от момента нажатия кнопочки "хочу купить" до команды на отправку товара со склада — может пройти час, а то и неделя, а то и вообще плюнуть и уйти. Будешь держать распределённую транзакцию открытой?
G>Вы процитировали кусок, как-будто не читали предыдущую переписку.
Каюсь, переписку я читал невнимательно. Скорее всего чего-то упустил.

G>Там много обсуждали разные задачи и конкретно этот кейс про задачу, которая может быть решена в рамках одной транзакции БД.
G>Или вы хотите сказать что вообще не надо опираться на транзакции БД потому что бывают бизнес-процессы, которые не укладываются в транзакции БД?
Так ведь вопрос идёт об архитектуре. Откуда так получилось, что разные независимые физические сущности оказались в одной БД? Склад, корзина пользователя, каталоги товаров — всё лежит в одном монолите... Удобно, конечно, но работает плохо, т.к. неверно моделирует реальность.

G>·>Это не в рамках МСА, а в реальном физическом мире не бывает атомарности. МСА это делает очевидным и заставляет выражать явно.
G>В рамках одного процесса вполне себе бывает.
Ну вот плохо получается, если моделировать одним процессом. Участники бизнес-процессов в реальном мире — независимы, географически распределены, работают параллельно.

G>>>И самое главное сможете ли вы с этим жить в будущем.
G>·>Хошь, не хошь, а придётся.
G>Угу, ровно до тех пор пока не появятся требования чтобы этого не было.
Законы физики требованиями не изменишь.

G>·>И нам придётся писать извинительное письмо "счастливому" клиенту, оплатить курьеру потраченное время и бензин, откатить платёж по кредитке, оплатив banking fees.
G>·>Вот такой он, откат атомарной транзакции.
G>Тут дело не в транзакции выдачи со склада, тут вы транзакционность потеряли парой шагов бизнес-процесса ранее.
Это разные транзакции в разных частях системы.

G>·>А как ты себе представляешь перевести огромную систему над которой работают десятки-сотни девов с одной версии на другую? У разных частей системы могут быть разные требования к памяти-процу-сети-диску.
G>Ну для команды в 25 человек я делал, ничего катастрофичного, тем более зачастую есть обратная совместимость.
G>Но я не знаю проблемы конкретно жабы, что там за проблема перехода с версии на версию. У меня в проекте сейчас работает C# 10-летней давности. Да, неэффективно по сравнению с текущей версией, но работает.
В мелкомасштабных проектах работает, да. А так банально даже не в версии дело, а скажем, есть Azul и Oracle. С разной стоимостью, лицензиями и разными свойствами. Да даже просто ключи запуска могут отличаться.

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

G>·>Это типичная ошибка "как дОлжно" vs "как оно физически работает". Ты описываешь идеальный мир с единорогами. Всё так, так и должно работать, спору нет, я тоже за всё хорошее и против всего плохого.
G>·>А потом внезапно получается, что от момента нажатия кнопочки "хочу купить" до команды на отправку товара со склада — может пройти час, а то и неделя, а то и вообще плюнуть и уйти. Будешь держать распределённую транзакцию открытой?
G>Вы процитировали кусок, как-будто не читали предыдущую переписку.
Каюсь, переписку я читал невнимательно. Скорее всего чего-то упустил.

G>Там много обсуждали разные задачи и конкретно этот кейс про задачу, которая может быть решена в рамках одной транзакции БД.
G>Или вы хотите сказать что вообще не надо опираться на транзакции БД потому что бывают бизнес-процессы, которые не укладываются в транзакции БД?
Так ведь вопрос идёт об архитектуре. Откуда так получилось, что разные независимые физические сущности оказались в одной БД? Склад, корзина пользователя, каталоги товаров — всё лежит в одном монолите... Удобно, конечно, но работает плохо, т.к. неверно моделирует реальность.

G>·>Это не в рамках МСА, а в реальном физическом мире не бывает атомарности. МСА это делает очевидным и заставляет выражать явно.
G>В рамках одного процесса вполне себе бывает.
Ну вот плохо получается, если моделировать одним процессом. Участники бизнес-процессов в реальном мире — независимы, географически распределены, работают параллельно.

G>>>И самое главное сможете ли вы с этим жить в будущем.
G>·>Хошь, не хошь, а придётся.
G>Угу, ровно до тех пор пока не появятся требования чтобы этого не было.
Законы физики требованиями не изменишь.

G>·>И нам придётся писать извинительное письмо "счастливому" клиенту, оплатить курьеру потраченное время и бензин, откатить платёж по кредитке, оплатив banking fees.
G>·>Вот такой он, откат атомарной транзакции.
G>Тут дело не в транзакции выдачи со склада, тут вы транзакционность потеряли парой шагов бизнес-процесса ранее.
Это разные транзакции в разных частях системы.

G>·>А как ты себе представляешь перевести огромную систему над которой работают десятки-сотни девов с одной версии на другую? У разных частей системы могут быть разные требования к памяти-процу-сети-диску.
G>Ну для команды в 25 человек я делал, ничего катастрофичного, тем более зачастую есть обратная совместимость.
G>Но я не знаю проблемы конкретно жабы, что там за проблема перехода с версии на версию.
В мелкомасштабных проектах работает, да. А так банально даже не в версии дело, а скажем, есть Azul и Oracle. С разной стоимостью, лицензиями и разными свойствами. Да даже просто ключи запуска могут отличаться.

G>У меня в проекте сейчас работает C# 10-летней давности. Да, неэффективно по сравнению с текущей версией, но работает.
Именно. А начнёшь переезд — заколебаешься для большого проекта.