MySQL Repeatable Уровень изоляции чтения и феномен Lost Update - PullRequest
Новая
       61

MySQL Repeatable Уровень изоляции чтения и феномен Lost Update

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

В Высокая производительность Java Persistence В разделе 6.3.3.3 книги написано, что феномен Lost Update возможен на уровне изоляции MySQL Repeatable Read.Это скриншот:

enter image description here

Предполагается следующее (уровень изоляции REEATABLE READ): 

              tx1                     |                tx2
-----------------------------------------------------------------------------------
START TRANSACTION;                    |
SELECT * FROM test WHERE id = 1;      |
( say, DB_TRX_ID = 7 at this moment)   |
                                      |
                                      |  START TRANSACTION;
                                      |  SELECT * FROM test WHERE id = 1;
                                      |  UPDATE test SET name="x" WHERE id = 1;
                                      |  COMMIT;(say, makes DB_TRX_ID = 10)
                                      |
UPDATE test SET name="y" WHERE id = 1;|
COMMIT;

Вопрос:

После фиксации tx1 MVCC обнаружит, что версия строки (DB_TRX_ID) больше не равна 7 (вместо 10), и выполнит откат?Или фиксация будет выполнена успешно, что приведет к потере обновления?

1 Ответ

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

На уровне изоляции повторяемого чтения не должен ли MySQL MVCC предотвращать потерянное обновление с использованием пессимистической блокировки на уровне базы данных, приводящей к откату транзакции?

В соответствии со стандартом SQL повторяемое чтение должно предотвращать:

  • грязное чтение
  • неповторяемое чтение

Стандарт ничего не говорит о потерянных обновлениях, поскольку стандарт был разработан, когда 2PL (двухфазныйБлокировка) был фактическим механизмом управления валютой.

Если вы используете 2PL, то уровень изоляции Repeatable Read действительно предотвратит Lost Update .

Тем не менее, MVCC может предоставлять Repeatable Reads через несколько версий кортежа, но для предотвращения Lost Updates им также нужен планировщик транзакций для отслеживания модификаций кортежа для записей, прочитанных определенной транзакцией.Очевидно, что InnoDB не работает таким образом.

не должен MySQL MVCC предотвращать Lost Update с использованием пессимистической блокировки на уровне базы данных, что приводит к откату транзакции

Теперь, если вы внимательно прочиталиВ главе Транзакции в моей книге High-Performance Java Persistence вы обнаружите, что MVCC не использует пессимистическую блокировку при повторяемом чтении.Единственными принятыми блокировками являются блокировки промежутка и следующего ключа, взятые в кластеризованном индексе, но они не предотвращают потерянные обновления.

MySQL использует пессимистическую блокировку только для Serializable, что обеспечивает модель управления параллелизмом 2PL, дажепри использовании механизма хранения InnoDB на основе MVCC.

...