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

S>Тут такой вопрос.

S>Допустим есть некая операция типа перевод с одного счета на другой с использованием внешних сервисов и своей базы данных. Оформлено в методе, скажем, Fun1.

S>Что-то может отвалиться, к примеру, временно может не работать внешний сервис — возникнет WebException или там временно перестанет работать база.

S>Вопрос такой — как вы реализуете повторный запуск/повторную попытку после исключения?

Недавно обсуждался вопрос связанный с распределенными транзакциями, это всё по той-же части.
Рассмотрим пример, Вы вызвали чей-то сервис, который успешно обработал запрос и зафиксировал результаты в БД, но в процессе формирования/отправки ответа неожиданно "прилёг", причем на пару часов, что не благоприятно поспособствует бесполезным повторным вызовам на вашей стороне в течении этого времени.
Получается, со стороны того сервиса транзакция/операция обработана успешно, но Вы об этом не узнали.

Решается это опять-же неким синхронизирующим ключом транзакции/операции и обработкой оного с обеих сторон.
Их сервис повторно получив запрос с данным ключом, по хорошему должен проверить по нему уже имеющийся результат обработки, и при наличии отправить его, включая штамп времени, когда он реально был обработан.
На Вышей стороне после получения ответа, нужно зафиксировать факт отправки по этому ключу, чтобы исключить его из очереди.

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

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

S>Тут такой вопрос.

S>Допустим есть некая операция типа перевод с одного счета на другой с использованием внешних сервисов и своей базы данных. Оформлено в методе, скажем, Fun1.

S>Что-то может отвалиться, к примеру, временно может не работать внешний сервис — возникнет WebException или там временно перестанет работать база.

S>Вопрос такой — как вы реализуете повторный запуск/повторную попытку после исключения?

Недавно обсуждался вопрос связанный с распределенными транзакциями, это всё по той-же части.
Рассмотрим пример, Вы вызвали чей-то сервис, который успешно обработал запрос и зафиксировал результаты в БД, но в процессе формирования/отправки ответа неожиданно "прилёг", причем на пару часов, что не благоприятно поспособствует бесполезным повторным вызовам на вашей стороне в течении этого времени.
Получается, со стороны того сервиса транзакция/операция обработана успешно, но Вы об этом не узнали.

Решается это опять-же неким синхронизирующим ключом транзакции/операции и обработкой оного с обеих сторон.
Их сервис повторно получив запрос с данным ключом, по хорошему должен проверить по нему уже имеющийся результат обработки, и при наличии отправить его, включая штамп времени, когда он реально был обработан.
На Вашей стороне после получения ответа, нужно зафиксировать факт отправки по этому ключу, чтобы исключить его из очереди.

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