Транзакция (информатика): различия между версиями

→‎Свойства транзакций: копипаста из статьи ACID
(→‎Свойства транзакций: копипаста из статьи ACID)
{{main|ACID}}
Одним из наиболее распространённых наборов требований к транзакциям и транзакционным системам является набор [[ACID]] (Atomicity, Consistency, Isolation, Durability). Требования ACID были в основном сформулированы в конце 70-х годов [[Джим Грей|Джимом Греем]]<ref>[http://research.microsoft.com/~gray/papers/theTransactionConcept.pdf Gray, Jim. The Transaction Concept: Virtues and Limitations. Proceedings of the 7th International Conference on Very Large Databases: pages 144—154, 1981]{{ref-en}}</ref>. Вместе с тем существуют специализированные системы с ослабленными транзакционными свойствами<ref>[http://www.informatik.uni-trier.de/~ley/db/books/collections/JajodiaK97.html Advanced Transaction Models and Architectures]{{ref-en}}</ref>.
 
=== Atomicity (атомарность) ===
{{main|Атомарность}}
 
Атомарность гарантирует, что никакая транзакция не будет зафиксирована в системе частично. Будут либо выполнены все её подоперации, либо не выполнено ни одной. Поскольку на практике невозможно одновременно и атомарно выполнить всю последовательность операций внутри транзакции, вводится понятие «отката» (rollback): если транзакцию не удаётся полностью завершить, результаты всех её до сих пор произведённых действий будут отменены и система вернётся в исходное состояние.
 
=== Consistency (согласованность) ===
В соответствии с этим требованием, система находится в согласованном состоянии до начала транзакции и должна остаться в согласованном состоянии после завершения транзакции.
 
Не нужно путать требование согласованности с требованиями целостности (integrity). Последние правила являются более узкими и, во многом, специфичны для [[Реляционная СУБД|реляционных СУБД]]: есть требования целостности типов (domain integrity), целостности ссылок (referential integrity), целостности сущностей (entity integrity), которые не могут быть нарушены физически в силу особенностей реализации системы.
 
Согласованность является более широким понятием. Например, в банковской системе может существовать требование равенства суммы, списываемой с одного счёта, сумме, зачисляемой на другой. Это бизнес-правило и оно не может быть гарантировано только проверками целостности, его должны соблюсти программисты при написании кода транзакций. Если какая-либо транзакция произведёт списание, но не произведёт зачисление, то система останется в некорректном состоянии и свойство согласованности будет нарушено.
 
Наконец, ещё одно замечание касается того, что ''в ходе'' выполнения транзакции согласованность ''не требуется''. В нашем примере списание и зачисление будут, скорее всего, двумя разными подоперациями и между их выполнением внутри транзакции будет видно несогласованное состояние системы. Однако не нужно забывать, что при выполнении требования изоляции никаким другим транзакциям эта несогласованность не будет видна. А атомарность гарантирует, что транзакция либо будет полностью завершена, либо ни одна из операций транзакции не будет выполнена. Тем самым эта промежуточная несогласованность является скрытой.
 
=== Isolation (изолированность) ===
{{см. также|Уровни изолированности транзакций}}
Во время выполнения транзакции параллельные транзакции не должны оказывать влияние на её результат. Это свойство не соблюдается на [[Уровень изолированности транзакций|уровне изолированности]] Repeatable Read и ниже.
 
=== Durability (долговременность, устойчивость) ===
Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании), изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу. Другими словами, если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя.
 
== Уровни изоляции транзакций ==
Анонимный участник