Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Введение
Вложенная транзакция — это транзакция базы данных, которая начинается инструкцией в области видимости уже запущенной транзакции. Вложенные транзакции реализуются по-разному в различных базах данных. Однако, общим для них является то, что изменения не становятся видимыми для несвязанных транзакций до тех пор, пока не будет зафиксирована самая внешняя транзакция. Это означает, что фиксация во внутренней транзакции не обязательно приводит к сохранению обновлений в системе. В некоторых базах данных изменения, внесенные вложенной транзакцией, не видны «родительской» транзакции до тех пор, пока вложенная транзакция не будет зафиксирована. По мнению некоторых, это вытекает из свойства изоляции транзакций. Возможность корректной обработки вложенных транзакций является необходимым условием для построения настоящих компонентно-ориентированных архитектур приложений. В инкапсулированной компонентной архитектуре вложенные транзакции могут возникать без ведома программиста. Функция компонента может содержать или не содержать транзакцию базы данных (это инкапсулированная особенность компонента. См. Информационное сокрытие). Если вызов такой функции компонента выполняется внутри блока BEGIN COMMIT, возникают вложенные транзакции. Поскольку популярные базы данных, такие как MySQL, не поддерживают вложение блоков BEGIN COMMIT, для обработки этого требуется фреймворк или монитор транзакций. Говоря о вложенных транзакциях, следует подчеркнуть, что эта функция зависит от СУБД и не доступна во всех базах данных. Теория вложенных транзакций аналогична теории плоских транзакций. Банковская индустрия обычно обрабатывает финансовые транзакции с использованием открытых вложенных транзакций, которые представляют собой более гибкий вариант модели вложенных транзакций, обеспечивающий более высокую производительность, но при этом допускающий компромиссы в отношении согласованности.
A nested transaction is a database transaction that is started by an instruction within the scope of an already started transaction. Nested transactions are implemented differently in different databases. However, they have in common that the changes are not made visible to any unrelated transactions until the outermost transaction has committed. This means that a commit in an inner transaction does not necessarily persist updates to the system. In some databases, changes made by the nested transaction are not seen by the 'host' transaction until the nested transaction is committed. According to some, this follows from the isolation property of transactions. The capability to handle nested transactions properly is a prerequisite for true component based application architectures. In a component based encapsulated architecture, nested transactions can occur without the programmer knowing it. A component function may or may not contain a database transaction (this is the encapsulated secret of the component. See Information hiding). If a call to such a component function is made inside a BEGIN COMMIT bracket, nested transactions occur. Since popular databases like MySQL do not allow nesting BEGIN COMMIT brackets, a framework or a transaction monitor is needed to handle this. When we speak about nested transactions, it should be made clear that this feature is DBMS dependent and is not available for all databases. Theory for nested transactions is similar to the theory for flat transactions. The banking industry usually processes financial transactions using open nested transactions, which is a looser variant of the nested transaction model that provides higher performance while accepting the accompanying trade offs of inconsistency.