578________________________________________________Глава 10,

Остальные процедуры приложения, вероятно, специальных комментариев не
требуют. Просмотрите их, проверьте, как работает приложение, и все неясности
разрешатся.

10.2 Работа с базами данных в сети            i

10.2.1 Транзакции и проблемы многопользовательского
режима работы

Все, что рассматривалось ранее, и все созданные вами приложения могут рабо-
тать и с локальными базами данных, и в сети с базами с разделенными файлами (с
одновременным доступом нескольких пользователей), и с удаленным сервером на
платформе клиент/сервер. Однако, при работе в сети, когда к одной и той же базе
данных одновременно может обращаться несколько пользователей, может возни-
кать множество проблем. Например, вы прочитали какую-то запись из таблицы и
редактируете ее. Но, пока вы редактируете, другой пользователь может изменить
эту запись или вообще удалить ее. Что тогда будет при попытке сохранить ваши
изменения в этой уже отредактированной или вообще удаленной записи?

Эта и множество других аналогичных проблем разрешаются с помощью меха-
низма транзакций (transaction). Транзакция — это групповая операция, связанная
с передачей сообщения. С точки зрения приложения транзакция — это группа ло-
гически связанных операторов SQL, причем только успешное выполнение всех
операторов должно приводить к изменению данных сервером. Пока все операторы
транзакции не выполнены, сохраняется возможность отменить их и не фиксиро-
вать результаты в базе данных. Подобный механизм необходим для надежной ра-
боты с удаленным сервером и в многопользовательском режиме. В тех приложени-
ях, которые вы создавали до сих пор, транзакции тоже использовались, но неявно.
Каждый вызов метода Post, каждое изменение таблицы автоматически начинало и
заканчивало транзакцию. Но часто такой автоматизм недостаточен и не эффекти-
вен. Обычно надо управлять транзакциями явно. Как это делается, мы рассмотрим
ниже. Но сначала попробуем осмыслить проблемы, возникающие при совместном
доступе пользователей к одной и той же таблице. Их можно систематизировать
следующим образом:

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

• Неповторяемое чтение данных происходит, если в момент чтения данных од-
ной транзакцией другая транзакция изменяет эти данные. В этом случае по-
вторное чтение тех же данных невозможно.

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

• Потерянные изменения возникают, если одна транзакция модифицирует из-
менения, сделанные другой транзакцией.

• Вторичные эффекты модификации могут происходить в базах данных, в ко-
торых значения одних записей зависят от значений других записей. Тогда на-
ложения результатов одновременной работы нескольких транзакций возмож-
ны даже в случае, если транзакции оперируют с разными записями.