BEGIN; BEGIN 204 UPDATE aircrafts_tmp

UPDATE aircrafts_tmp
SET range = range + 200
WHERE aircraft_code = 'SU9';
И вот мы видим, что команда UPDATE во второй транзакции не завершилась, а пере-
шла в состояние ожидания. Это ожидание продлится до тех пор, пока не завершится
первая транзакция. Дело в том, что команда UPDATE в первой транзакции заблоки-
ровала строку в таблице airctafts_tmp, и эта блокировка будет снята только при завер-
шении транзакции либо с фиксацией изменений с помощью команды COMMIT, либо
с отменой изменений по команде ROLLBACK.
Давайте завершим первую транзакцию с фиксацией изменений:
COMMIT;
COMMIT
Перейдя на второй терминал, мы увидим, что команда UPDATE завершилась:
UPDATE 1
Теперь на втором терминале, не завершая транзакцию, посмотрим, что стало с нашей
строкой в таблице aircrafts_tmp:
SELECT * FROM aircrafts_tmp WHERE aircraft_code = 'SU9';
aircraft_code |
model
| range
---------------+---------------------+-------
SU9
| Sukhoi SuperJet-100 | 3300
(1 строка)
Как видно, были произведены оба изменения. Команда UPDATE во второй транзак-
ции, получив возможность заблокировать строку после завершения первой транзак-
ции и снятия ею блокировки с этой строки,
перечитывает
строку таблицы и потому
обновляет строку, уже обновленную в только что зафиксированной транзакции. Та-
ким образом, эффекта потерянных обновлений не возникает.
Завершим транзакцию на втором терминале, но при этом вместо команды
COMMIT воспользуемся эквивалентной командой END, которая является расшире-
нием PostgreSQL:
END;
COMMIT
Если вы самостоятельно проведете только что выполненный эксперимент, выбрав
уровень изоляции READ UNCOMMITTED, то увидите, что и на этом — самом низком —
уровне изоляции эффекта потерянных обновлений также не возникает.
Для иллюстрации эффекта неповторяющегося чтения данных проведем совсем про-
стой эксперимент также на двух терминалах.
На первом терминале:

жүктеу/скачать 3,05 Mb.

Достарыңызбен бөлісу: