/

Из г шаг за
Ну. Б эээ. Х. З и

да.
Но вот это утверждение не верно: "клиенту подтверждения не было, он вправе считать, что был откат"
Если связь с сервером оборвалась, то статус транзакции клиенту не известен. Она может оказаться как закоммиченной, так и нет.

я исхожу из того, что транзакция либо подтверждена и зафиксирована. либо нет. т.е. тут всё строго должно быть.
ибо SQL как язык не даёт возможности проверить статус транзакции

@dimuska139
что думаешь об этом?

Транзакция это не кот Шрёдингера. Она действительно закоммичена или нет.
Но только клиент про это может не знать.
Вы что то попросили, вам ответили, а вы ответ не услышали... Было ли выполнено то, что вы просили?

Я вообще не в теме))))

закоммиченность или нет транзакции это забота клиента, если он не получил исключение, значит все прошло как надо

но бывают редкие случаи когда сервер виноват, об этом говорят выше

в ситуации, когда:
- клиент явно начал транзакцию через COMMIT
- сервер “ушёл” по не зависящим от клиента причинам ничего не сообщив
- иными словами, клиент не получил подтверждение фиксации

клиент вправе считать транзакцию оборванной, ибо ACID

если клиент послал коммит ушел в айдл с потерей пакетов - это его проблемы, он не получил исключение, значит все нормально. А то что он получит тайм-аут - это его проблемы, и его сети, а не сервера. Сервер получил коммит и сделал что от него требовалось.

тогда такой вопрос... как с точки зрения бэкенд-разработки обрабатывать такую ситуацию.

ты пишешь код, который делает update в БД. но в процессе апдейта, сетевое соединение до БД может оборваться (не такая уж и редкая ситуация). Как мне кажется класический вариант посчитать это ошибкой и вернуть клиенту ошибку. Но при этом апдейт по факту может завершиться и стейт в БД изменится так как и хотел клиент (хотя клиенту то приложение вернуло ошибку)

я не говорю про тупняки, не передёргивайте. я говорю о счастливом случае когда мастер-база умирает в определённый момент

Ребята, ну давайте же думать логически.
Сёрвер в какой-то момент должен принять решение: ибо, как было сказано - ACID.
Ну вот он его принял.
Ну клиент об этом ещё не знает. Между ними километры оптоволкна, IP-стэк и ещё куча всякой фигни.
Но решение уже принято. И от того, подучит ли клиент ответ или нет - ничего уже не зависит.

это вы передергиваете "тупняками", я говорю что проблемы сети клиента - это не проблемы сервера.

а я про проблемы сети клиента ни разу ничего и несказал

Если сервер не сказал явно, что транзакция завалена, это успешный коммит. Примерно как вызвать такси и закрыть приложение, не дождавшись уведомления о том, что тачка приехала.

Надо проверить статус - надо послать селект и проверить, если сеть отвалилась. Восстановить состояние клиента до актуального.

То, что клиенту в таком случае надо ошибку показывать - это точно. Ну а саму ситуацию надо просто логировать (то, какой метод вызывался, с какими параметрами и какая ошибка возникла) - и по логам уже разбираться, что там произошло. Я логи ошибок, например, смотрю ежедневно. Если надо - лезу в базу. То есть ситуацию, когда для юзера апдейт не прошёл, а по факту прошёл - можно выявить. Вопрос правда ещё в том, к каким последствиям всё это приводит.

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