Отменяемые наборы изменений

Question

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

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

Я придумал модуль, который складывает «измененные» объекты, которые в свою очередь имеют свои методы init, commit и rollback.Когда набор УНИЧТОЖЕН, он откатывает незафиксированные изменения обратно.Это вроде работает.

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

Answer 1

Существует несколько подходов к выполнению Распределенной транзакции (это то, что вы описываете):

1. Стандартный шаблон называется " Двухфазная фиксация протокол".

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

2. В некоторых случаях возможно решение с откатом через « Компенсирующие транзакции ».

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

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