Изолированность и устойчивость данных

Проблемы параллельного выполнения программ известны уже давно, и за это время предложено немало вариантов их решения. Для корпоративных приложений особенно важны два решения: поддержка изолированности (isolation) и обеспечение устойчивости (immutability) данных.

Подобные проблемы возникают в ситуациях, когда несколько активных агентов, таких, как процессы или потоки вычислений, обращаются к одной и той же порции информации. Один из вариантов разрешения возможных конфликтов состоит в изоляции данных таким образом, чтобы к любому их элементу мог адресоваться только один агент. Процессы прикладной программы протекают так же, как их аналоги уровня операционной системы: процесс получает в свое безраздельное владение участок оперативной памяти, и только этот процесс способен считывать и сохранять ассоциированные с ним данные. Схожим образом действуют и схемы блокирования файлов, применяемые во многих популярных приложениях. Если файл открыт Мартином, в этот период никто другой открыть его уже не сможет; в крайнем случае система разрешит обратиться к файлу в режиме «только для чтения» и просмотреть ту версию данных, которая соответствовала началу сеанса работы Мартина. На протяжении всего сеанса никто не сможет изменить содержимое файла и увидеть какую бы то ни было промежуточную информацию, сохраняемую Мартином.

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

Проблемы, связанные с параллельным доступом к данным, возникают только тогда, когда общие фрагменты таких данных подвержены изменениям. Один из естественных способов предотвращения потенциальных конфликтов заключается в обнаружении устойчивых (immutable) элементов информации. Совершенно очевидно, что придать статус устойчивости всем данным не удастся, поскольку основное назначение многих систем как раз и состоит в обеспечении средств модификации информации. Но если определить некоторые порции данных как устойчивые или, по меньшей мере, устойчивые в продолжение некоторых периодов, можно ослабить ограничения параллельного доступа. Еще одна альтернатива — отделить приложения, функционирующие в режиме «только для чтения», от всех остальных и заставить их работать с копиями источников данных, что значительно упростит логику управления доступом.

Транзакции

Транзакции (transactions) — основной инструмент управления параллельными процессами в корпоративных приложениях.

Транзакции в программных системах часто описывают в терминах свойств, обозначаемых общей аббревиатурой ACID.

• Atomicity (атомарность). В контексте транзакции либо выполняются все действия, либо не выполняется ни одно из них. Частичное или избирательное выполнение недопустимо. Например, если клиент банка переводит сумму с одного счета на другой и в момент между завершением расходной и началом приходной операции сервер терпит крах, система должна вести себя так, будто расходной операции не было вовсе. Система должна либо осуществить обе операции, либо не выполнить ни одной. Фиксация (commit) результатов служит свидетельством успешного окончания транзакции; откат (rollback) приводит систему в состояние, в котором она пребывала до начала транзакции.

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

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

• Durability (устойчивость). Результат выполнения завершенной транзакции не должен быть утрачен ни при каких условиях.

Ресурсы транзакций

В большинстве случаев под транзакциями в корпоративных приложениях подразумеваются последовательности операций, описывающие процессы взаимодействия с базами данных. Но существует и множество других объектов, управляемых с помощью механизмов поддержки транзакций, например, очереди сообщений или заданий на печать, банкоматы и т.д. Таким образом, термин «ресурсы транзакций» служит для обозначения всего, что может быть затребовано параллельно протекающими процессами, определяемыми с помощью модели транзакций. Наиболее распространенным ресурсом транзакций являются базы данных. Поэтому для наглядности и краткости упоминаются именно они, хотя все сказанное вполне применимо и к другим видам ресурсов.

Для обеспечения высокого уровня пропускной способности современные системы управления транзакциями проектируются в расчете на максимально короткие транзакции. Обычно из практики исключаются транзакции, которые охватывают действия по обработке нескольких запросов; если же подобной ситуации избежать не удается, решения реализуются на основе схемы длинных транзакций (long transactions).

Чаще, однако, границы транзакции совпадают с моментами начала и завершения обработки одного запроса. Подобная транзакция запроса (request transaction) — весьма удачная модель, и многие среды поддерживают простой и естественный синтаксис ее описания.

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

Применяя транзакции, следует понимать, что именно надлежит блокировать. Во многих случаях диспетчер транзакций СУБД блокирует отдельные записи таблицы базы данных, вовлеченные в операцию, что позволяет сохранить высокий уровень параллелизма при доступе к таблице. Но если транзакция пытается блокировать слишком большое количество записей таблицы, число запросов на блокировку превышает допустимый лимит и система распространяет действие блокировки на таблицу в целом, приостанавливая выполнение конкурирующих транзакций. Подобное расширение блокировки (lock escalation) способно серьезно сократить потенциал параллельного доступа к данным, что практически запрещает другим процессам и потокам иметь доступ к базе данных.