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

S>Вот это и есть дизайн в стиле безумного шляпника, который создаёт вам проблемы.

Говорите конкретно что не так.

S>Пока что вы описали ровно вариант "получить результат запроса". Если пользователь отключился — всё, результат ему не нужен.

Он вышел, но программу не закрыл — старые операции продолжают работать. Механизма отмены нет.

S>Зачем вы берётесь записывать этот результат в какие-то таблицы? Пользователь явно выразил своё намерение завершить сессию. Нужно ли извещать сервер о том, что результат не нужен — дело вкуса.

Весь вопрос в том — как делать отмену. Будете ли вы встраивать в каждый сетевой запрос возможность отмены?

S>>Какая тут может быть атомарность?
S>Очень простая. Но детали сильно зависят от того, что именно делает приложение. С учётом окружающих рассуждений, велики шансы на то, что вы вместо одного из двух типовых паттернов изобрели ещё какое-то безумие.

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

S>Поэтому советы по реализации давать трудно.
S>Остаётся только повториться: вы делаете какую-то дичь, именно поэтому никакие типовые решения вам не подходят. Ни в какой области. Ни в области персистенса, ни в области асинхронного программирования, ни в области обработки ошибок.

Так напишите как вы решите задачу:

1. Пользователь сделал запрос к серверу от имени Вася.
2. Пока идет запрос — пользователь Вася вышел и зашел под пользователем Петя. Программу не останавливали.
3. Пришел запрос, но теперь текущий пользователь — Петя.
4. ?

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

S>Вот это и есть дизайн в стиле безумного шляпника, который создаёт вам проблемы.

Говорите конкретно что не так.

S>Пока что вы описали ровно вариант "получить результат запроса". Если пользователь отключился — всё, результат ему не нужен.

Он вышел, но программу не закрыл — старые операции продолжают работать. Механизма отмены нет.

S>Зачем вы берётесь записывать этот результат в какие-то таблицы? Пользователь явно выразил своё намерение завершить сессию. Нужно ли извещать сервер о том, что результат не нужен — дело вкуса.

Весь вопрос в том — как делать отмену. Будете ли вы встраивать в каждый сетевой запрос возможность отмены?

S>>Какая тут может быть атомарность?
S>Очень простая. Но детали сильно зависят от того, что именно делает приложение. С учётом окружающих рассуждений, велики шансы на то, что вы вместо одного из двух типовых паттернов изобрели ещё какое-то безумие.

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

S>Поэтому советы по реализации давать трудно.
S>Остаётся только повториться: вы делаете какую-то дичь, именно поэтому никакие типовые решения вам не подходят. Ни в какой области. Ни в области персистенса, ни в области асинхронного программирования, ни в области обработки ошибок.

Так напишите как вы решите задачу:

1. Пользователь сделал запрос к серверу от имени Вася.
2. Пока идет запрос — пользователь Вася вышел и зашел под пользователем Петя. Программу не останавливали.
3. Пришел ответ запрос, но теперь текущий пользователь — Петя.
4. ?