Шаблоны для реализации транзакций за пределами базы данных

Windows Workflow Foundation имеет понятие компенсации (использующий Составное действие), когда семантика ACID не могла бы быть соответствующей.. От курса это имеет поддержку транзакций ACID также.

Хороший вопрос состоит в том почему беспокойство с компенсацией? Разве одна большая транзакция ACID с автоматическим откатом не так хороша? Транзакция ACID является самой соответствующей, когда операции происходят в той же базе данных или в той же информационной системе. Является также самым уместным, когда операции заканчиваются быстро. Когда различные компании и службы вовлечены, определение процесса с точки зрения семантики ACID часто сложно. Чтобы это было изолировано и длительно, необходимо сохранить все ресурсы различных компаний заблокированными на время задачи. Это часто неблагоразумно, особенно если задача долга. Чтобы это было последовательным и атомарным, Вам нужен специальный код компенсации.

Так как Вы не можете не отправить электронное письмо, и это относительно недорого для записи файла, я просто сделал бы те вещи в надлежащем порядке:

1. Попытайтесь записать файлу/записи файл. Если неудачный, остановитесь, иначе продолжите:
2. Назовите веб-сервис. Если неудачный, удалите файл и остановку, иначе продолжите:
3. Пошлите электронное письмо - электронная почта является асинхронной во всяком случае, таким образом, Вы действительно никогда не знали бы, было ли это отправлено или не, так как большинство почтовых серверов установлено повторить в течение нескольких дней, если ошибка происходит, и Вы никогда не возвращаете подтверждение, которое прошла электронная почта, даже если это было успешно.

Самая простая техника, не полагаясь в большой степени на внешнюю библиотеку является распространенностью. Периодически контрольная точка при помощи сериализации для взятия снимка состояния затем поддержите журнал путем сериализации достаточной информации о каждой операции стороны-effectful против данных для повторения его позже. Если что-то аварийно завершается, перезагрузите новую контрольную точку, то повторно примените все записи журнала, записанные после той точки.

Для чего-то более сложного попробуйте программное обеспечение транзакционная память. Это может быть несколько неуклюже для реализации на текущих языках, но довольно мощно и может дать Вам некоторые дополнительные методы параллелизма также.

Для необратимых операций как доступ к веб-сервису или отправка электронного письма, необходимо будет использовать компенсацию транзакций: выполните другой вызов веб-сервиса, чтобы отменить или обновить результаты предыдущего или возможно послать другое электронное письмо, советуя получателю, что вещи не работали, как предназначено.

Две мысли:

• Как Jeffrey Hantin упоминает, программное обеспечение транзакционная память (STM) довольно сладко. Смотрите на то, как это реализуется/используется в Clojure; видео Богатого Пятна являются впечатляющими.
• Одним важным аспектом Шаблона "команда" известности GoF является "undoability". Реализация этого могла бы свести к простому (но тем не менее полезный) предложение Robert C. Barth

Одна из идей состоит в том, чтобы использовать JMS в качестве «механизма», и вы можете использовать транзакции JMS (которые могут присоединяться к существующим транзакциям, например, транзакции БД). Это начинает вести к асинхронной архитектуре, управляемой событиями, что, вероятно, хорошо, если мы не говорим о простых приложениях - в этом случае вам, вероятно, не нужно задавать вопрос.

Примером этого может быть простая учетная запись творчество. Для этого вы хотите сохранить информацию об учетной записи в БД, а также отправить пользователю электронное письмо для активации, но вы хотите, чтобы они были в одной транзакции по очевидным причинам.

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

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

Важнее всего то, что запись в БД согласована, и в конечном итоге электронное письмо будет отправлено.

Также недавно был выпущен экспериментальный проект STM .NET . Этот проект добавляет в C # память транзакций. Фактически он модифицирует CLR для поддержки этого.