Избегайте грязных / фантомных чтений при выборе из базы данных - PullRequest
0 голосов
/ 13 ноября 2018

У меня есть две таблицы A и B.

Мои транзакции такие:

  • Чтение -> чтение из таблицы A
  • Запись -> запись в таблицу B, запись в таблицу A

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

Вот пример:

  1. Транзакция 1 - обновление происходит в таблице B
  2. Транзакция 2 - Чтение происходит в таблице A
  3. Транзакция 1 - обновление происходит в таблице A
  4. Транзакция 2 - Завершено
  5. Транзакция 1 - откат

Теперь клиент Transaction 2 содержит грязные данные. Как мне этого избежать?

1 Ответ

0 голосов
/ 14 ноября 2018

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

Предполагается, что ваша база данных зарегистрирована - здесь не имеет значения, буферизована ли она или нет буферизованной регистрации или (в основном) база данных MODE ANSI - тогда, если вы не установите изоляцию DIRTY READ, вы работаете с использованием по меньшей мере изоляции COMMITTED READ ( это будет уровень REPEATABLE READ от Informix, уровень SERIALIZABLE стандартного SQL, если база данных MODE ANSI).

Если вы хотите убедиться, что строки данных не изменились после того, как транзакция их прочитала, вам нужно работать с более высокой изоляцией - REPEATABLE READ. (Подробнее см. SET ISOLATION в руководстве. (Остерегайтесь номенклатуры для SET TRANSACTION ; есть раздел руководства о Сравнение SET ISOLATION и SET TRANSACTION и связанных с ним разделов.) Недостатком использования SET ISOLATION для повторяемого чтения (или SET SERACIZAL LEVEL ISOLATION LEVEL SERIALIZABLE) является то, что необходимые дополнительные блокировки уменьшают параллелизм - но дают вам лучшие гарантии о состоянии базы данных.

...