Изучаем Java EE 7

Вы можете себе представить последовательность операций в базе данных, выполняемых при переводе денег с одного счета на другой: с резервного счета деньги списываются с помощью оператора SQL update, на текущий счет деньги зачисляются с помощью другого оператора update, а также в другой таблице создается файл журнала, который используется для слежения за переводами. Эти операции должны выполняться над одной единицей работы (Атомарность), поскольку вы не хотите, чтобы деньги были списаны с одного счета и при этом не были зачислены на другой. С точки зрения внешних приложений, получающих доступ к счетам, результат операций должен быть виден только после выполнения всех операций (Изолированность). Если это условие выполняется, то внешнее приложение не может увидеть промежуточное состояние, когда с одного счета деньги уже списаны, а на другой еще не зачислены (если бы это произошло, приложение посчитало бы, что пользователь имеет меньше денег, чем на самом деле). Согласованность проявляется в том, что операции транзакции (как фиксация, так и откат) выполняются в рамках ограничений базы данных (например, первичных ключей, отношений или полей). После завершения перевода данные могут быть доступны из других приложений (надежность).

Условия считывания

Изолированность транзакции может быть определена с использованием различных условий чтения (грязное, повторяемое и фантомное чтение). Эти условия описывают, что может произойти, когда две или более операции действуют с одними и теми же данными одновременно.

В зависимости от применяемого уровня изоляции можно полностью избежать или разрешить одновременный доступ к данным.

• Грязное чтение — происходит, когда транзакция считывает незафиксированные изменения, сделанные предыдущей транзакцией.

• Повторное чтение — происходит, когда считанные данные гарантированно будут выглядеть так же, если читать их снова в той же транзакции.

• Фантомное чтение — происходит, когда новые записи, добавленные в базу данных, могут быть обнаружены теми транзакциями, которые начались до операции вставки. Запросы будут включать в себя записи, добавленные другими транзакциями после того, как началась их текущая транзакция.

Уровни изоляции транзакций

Базы данных используют несколько различных методов блокировки для управления одновременным доступом к данным. Механизмы блокировки воздействуют на условия чтения, описанные ранее. Уровни изоляции обычно используются в базах данных и описывают, как блокировка применяется к данным в рамках транзакции. Рассмотрим четыре типа уровней изоляции.

• Чтение незафиксированных данных (менее ограничительный уровень изоляции) — транзакция может читать незафиксированные данные. Может произойти грязное, неповторяемое и фантомное чтение.

• Чтение зафиксированных данных — транзакция не может читать незафиксированные данные. Предотвращается грязное чтение, но не неповторяемое или фантомное.

• Повторяемое чтение — транзакция не может изменить данные, которые считываются другими транзакциями. Предотвращается грязное и неповторяемое чтение, но фантомное все еще может произойти.

• Сериализуемое (наиболее строгий уровень изоляции) — транзакция имеет эксклюзивное право на чтение. Другие транзакции не могут ни читать, ни записывать эти же данные.

Вообще говоря, если уровень изоляции становится более ограничительным, производительность системы снижается из-за того, что операции не могут получить доступ к одним и тем же данным. Тем не менее уровень изоляции обеспечивает согласованность данных. Обратите внимание, что не все СУБД реализуют все четыре уровня изоляции.

Локальные транзакции JTA

Для того чтобы транзакции работали как положено, должны присутствовать некоторые компоненты, а также должны выполняться свойства ACID. Сначала рассмотрим простейший пример приложения, выполняющего несколько изменений единого ресурса (скажем, базы данных). Когда существует только один транзакционный ресурс, все, что вам потребуется, — это локальные транзакции JTA. Локальная транзакция ресурса — это транзакция, при осуществлении которой у вас имеется какой-то определенный ресурс, использующий свой специфический API. На рис. 9.1 показано приложение, взаимодействующее с ресурсом через менеджер транзакций и менеджер ресурсов.

Рис. 9.1. Транзакция с участием одного ресурса

Компоненты, показанные на рис. 9.1, помогают отделить обработку транзакции от бизнес-логики самого приложения.

• Менеджер транзакций — основной компонент, отвечающий за управление операциями транзакций. Он создает транзакции от имени приложения, информирует менеджер ресурсов, что он участвует в сделке (операция, известная как задействование) и проводит фиксацию или откат в менеджере ресурсов.