12. Основные принципы управления тран-ями.

Тран-я, или атомарная тран-я, — это логический модуль, действия кото­рого должны быть выполнены полностью или не выполнены вовсе. Понятие атомар­ность заимствовано из физики и имеет тот же смысл: единица (модуль), которая не может быть разбита на меньшие составляющие.

Тран-я — это также и декларативная единица, т.е. разработчик прил декларирует некоторую совокупность действий БД как транзакцию. Прил будет выполнять эти действия как модуль. Если при выполнении данной совокупности действий возникают какие-либо проблемы, должны быть отменены все созданные этими действиями изменения и восстановлено предвари­тельное состояние.

Все операции доступа к базам данных и особенно все модификации БД должны выполняться как часть тран-ии. Прил подключается к серверу БД и обращается с запросом на создание (открытие) новой тран-ии. Серии запросов и обновлений выполняются прилм в пределах открытой тран-ии. Затем прил может выполнить фиксацию (commit) тран-ии, тем самым признавая окончательными все обновления, или же вы­полнить откат (rollback) тран-ии, тем самым отменяя все обновления и воз­вращая базу данных в исходное состояние. Промежуточных состояний нет. Или все обновления фиксируются в базе данных, или же состояние БД не подвергается воздействию тран-ии вообще. После того как тран-я закры­та, вследствие операции фиксации или отката, для последующего доступа к базе данных прил должно открыть новую транзакцию.

В теории и практике БД определяются четыре важнейших свойства тран-ий, сокращенно именуемых ACID (аббревиатура от английского названия свойств: атомарность, согласованность, изолированность и продолжительность).

• Атомарность (atomicity). Или все обновления тран-ии происходят успешно, или же никаких обновлений не происходит вовсе.

• Согласованность (consistency). Каждая тран-я должна оставлять базу данных в согласованном состоянии. Свойства, подобные ссылочной целостности, не должны нарушаться.

• Изолированность (isolation). При параллельном выполнении нескольких тран-ий результат выполнения каждой из тран-ий должен быть тем же, что и при ее отдельном выполнении.

• Продолжительность (durability). После успешного завершения тран-ии про­изведенные ею в базе данных изменения должны становиться перманентными. Даже серьезные сбои не должны нарушать перманентность тран-ии.

Большинство систем с СУБД поддерживают широкий набор типов тран-ий. Например, Oracle работает с тран-ями запроса, обновления, вставки и удаления.

Операции тран-ии

Для сервера БД выполнение тран-ии состоит из последовательности запросов доступа к объектам БД. Каждый такой запрос, или операция, опре­деляет операцию считывания объекта, операцию записи в объект, операцию фикса­ции или операцию отката. Каждая тран-я характеризуется последо­вательностью ее операций. Каждый сервер БД содержит менеджер тран-ий — программу, которая отслеживает поведение тран-ий и принимает решение о предоставлении разрешения на выполнение каждой операции. В частности, менеджер тран-ий отвечает за соблюдение множества протоколов тран-ий.

Атомарность тран-ии в системе, одновременно выпол. одну транз-ию

В системе с ед транз-ей в любой произвольный момент времени выполняется только одна тран-я. Если некая тран-я активна, никакая другая тран-я не может начаться. Эта ситуация в точности совпадает с ситуацией, в ко­торой в каждый момент времени к серверу БД подключено единственное прил, имеющее только одну активную транз-ию. Прил не может на­чать новую транзакцию до тех пор, пока не завершена предыдущая.

Для обеспечения атомарности сервер БД должен поддерживать операции открытия, фиксации и отката тран-ии. Операция отката вызывает наибольшие трудности. Если тран-я производит изменения, а затем отменяется, БД должна быть возвращена в прежнее состояние.

По умолчанию для тран-ий задается режим автофиксации, в котором каждый оператор языка SQL выполняется как отдельная тран-я. Выполнение SQL-оператора начинается с неявного запроса открыть транзакцию, после чего следует об­работка оператора, за которой автоматически следует запрос фиксации. Откат случа­ется только при сбое выполнения SQL-оператора.

Чтобы войти в режим явной фиксации, позволяющий выполнять несколько SQL-операторов в рамках одной тран-ии, прил должно произвести явный вызов менеджера тран-ий БД. Прил выполняет оператор открытия тран-ии, чтобы запросить менеджер тран-ий создать новую транзакцию перед вы­полнением следующего SQL-оператора. Чтобы запросить менеджер тран-ий за­фиксировать транзакцию, прил выполняет оператор фиксации тран-ии, а чтобы осуществить отмену тран-ии — оператор отката.

Тран-я может быть отменена по многим причинам. Простейшая ситуация возникает, когда выполняющее транзакцию прил обнаруживает некоторую проблему и инициирует операцию отката. Более сложные сценарии получаются при неожиданном прекращении выполнения прил или разрыве подключения между базой данных и прил-ем. Поведение операции отката не зависит от причины возникновения требующей отката ситуации. Рассмотрим простую ситуацию, когда тран-я отменяется по "воле" прил.

Чтобы осуществить откат тран-ии, система должна отслеживать произведенные транзакцией изменения. Для этого необходимо сохранять во временной области либо вносимые изменения, либо исходное состояние.

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