Comments 8
Может, я чего-то не понял, но вы говорите, что транзакций быть не должно, а потом пишете
"… Как только этот объект достигает конечного состояния, все изменения применяются к дочерним контролируемым объектам — одновременно, создавая несколько строк в журнале событий, по одной на атомарное действие.Таким образом, у нас всегда есть возможность откатить что-либо впоследствии."
Тут возникают вопросы, а как вы порядок гарантируете, ведь одновременно пишется только одна запись? Откат или фиксация нескольких действий — это не транзакция?
Ну да, вы назвали это транзакционным КА — но где принципиальная разница?
Спасибо за разъяснения.
Мне нелегко далась терминология в этом куске, да, пардон.
Вообще без транзакций, мы, очевидно, не можем. Но мы можем без транзакций, которые возможно откатить только, пока мы ее не закоммитили (как в СУБД). То есть, например, вот такой код
transaction {
a.update()
a.b.insert()
a.update_again()
}— очевидное зло, которое разбивается на три изменения состояния контролирующего объекта, и создает (кроме служебных) — три записи в логе. Они откатываемы, одна за другой.
Распределенные таймстемпы тоже можно поддерживать, есть несколько работ в интернетах о том, как; но тут это даже не нужно: мы просто пишем таймстемпы по контролирующему объекту (изменения которого тоже создают записи в логе).
Ну, с откатом, допустим, понятно. Сложности есть, но они решаемы.
А что с видимостью изменений?
Ведь, зачастую, другие участники не должны видеть изменения из транзакции пока их не закоммитят(ну и дальше "по учебнику" про уровни изоляции), или у вас это, вообще не нужно?
Как вы обеспечиваете консистентность инсертов?
Другие участники их и не видят, я распишу подробно, как только до компьютера дойду.
Но в конце-концов "коммит" должен произойти, разве не так?
Иначе, какой смысл и различия с транзакцией на максимальном уровне изоляции?
Да, внутри можно оптимизировать шаги выполнения, но принципиальная разница мне не видна.
То, что, локальные изменения можно откатить — тоже не нерешаемая задача.
В общем, давайте детали, лучше, вообще отдельным постом.
какой смысл и различия с транзакцией на максимальном уровне изоляции?
Я тут транзакциями называю что-то типа банковских транзакций. Которые могут длиться часами. При этом я не могу совсем изолироваться от окружающего мира, ну, например, доступная сумма на счету должна на время этой транзакции уменьшиться.
Если я по-настоящему уменьшу сумму, откат превратится в кошмар, как только таких параметров станет десять. Проще всего сделать так, чтобы окружающий мир получал интересующие его данные по состоянию «как сейчас», но при этом мы бы не трогали настоящие объекты в хранилище, пока не станет понятно, что с ними все-таки надо сделать.
Для этого на каждую такую «долгую» транзакцию создается отдельный объект (это возможно и с обычным хранилищем, но у нас, спасибо мирозданию, эрланг/otp, поэтому мы просто запускаем процесс). Этот процесс реализует FSM транзакции, и все участвующие объекты на время выполнения помечаются, как «in-tranaction». Это означает, что все попытки их изменить будут пресечены, а попытки их прочитать будут делегированы этому процессу-надзирателю.
Когда процесс дойдет до финального состояния, он либо все запишет в поднадзорные объекты (commit), либо не запишет и просто откатит их стейт (rollback), а также запишет себя как атомарную операцию, в event log. Код этого же процесса отвечает за откат, то есть, если нам потребуется откатить, мы будет откатывать эту единственную запись в логе, а код процесса будет знать, что с этим делать (например, выполнить еще один перевод обратно).
То, что, локальные изменения можно откатить — тоже не нерешаемая задача.
Можно, и мы так делали до этого. Но дело в том, что код мгновенно превращается в лапшу, когда в игру вступают посторонние сервисы. В FSM этого процесса, грубо говоря, такие шаги: сходить в А, сходить в Б, сходить в В, сходить в Д, выполнить. В зависимости от того, на каком шаге произошел отказ, оно ветвится. Может оказаться в «manual intervention required». При этом, все участвующие объекты должны из внешнего мира быть видны по-разному.
Надеюсь, смог быть чуть внятнее.
Не боги горшки обжигают