Неудачные наборы изменений

Question

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

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

Я придумал модуль, который складывает объекты «смены», которые, в свою очередь, имеют методы инициализации, фиксации и отката. Когда набор DESTROYed, он откатывает незафиксированные изменения. Этот вид работает.

По-прежнему я не могу преодолеть ощущение придумано колесо. Существует ли стандартный CPAN-модуль или хорошо описанный общий метод для выполнения такой задачи? (По крайней мере, GoF в «команда» модель и принцип RAII приходят на ум ...)

Answer 1

Есть несколько подходов к выполнению Distributed transaction (что вы описываете):

1. стандартный шаблон называется «Two-phase commit протокол».

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

2. В некоторых случаях возможно решение с откатом через «Compensating transactions».

   Это в основном частный случай общего отката, когда при создании списка задач А, предназначенного для изменения целевого состояния системы с S1 на S2, вы одновременно генерируете «компенсирующий» список задач A-neg, предназначенный для изменения состояние целевой системы от S2 до S1. Это, очевидно, возможно только для некоторых систем, и, кроме того, только небольшое их количество является коммутативным (это означает, что вы можете выполнять транзакцию и ее компенсирующую транзакцию не соприкасаясь, например, результат A + B + A-neg + B-neg является инвариантным состоянием.

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