PostgreSQL всегда использовал модель многоверсионности (MVCC — Multi-Version Concurrency Control) для управления конкурентностью транзакций. Эта модель основана на использовании снимков данных (snapshot isolation) и была реализована с самого начала. Документация PostgreSQL 7.1.
Я немного запутал тем, что сначала начинается транзакция 2, а потом транзакция 1 (в тексте ниже это написано). Исправлю на картинке на транзакции 3 и 4 (чтобы нумерация была по порядку, как и на самом деле в Postgres).
А "фантомное чтение" тут имеется. Дело в том, что Repeatable Read предотвращает неповторяющиеся чтения для существующих строк, но НЕ для новых строк, которые могут быть добавлены другой транзакцией и удовлетворять условиям запроса. Что как раз изображено на рис. 2.13.
С точки зрения бизнес-логики это правильно, но не с точки зрения изоляции транзакций.
UNIQUE и EXCLUDE вызывают блокировки при проверке ограничений.
Также, если одна транзакция удаляет или изменяет запись, на которую ссылается другая запись через внешний ключ, другая транзакция, которая пытается создать или изменить запись, ссылающуюся на удаляемую или изменяемую запись, может быть заблокирована. Вторая транзакция должна ждать, пока первая транзакция завершится, чтобы проверить, остается ли ссылка валидной.
Уточню, что можно обойтись лишь одним nginx, вместо двух, если в frontend конфигурации прописать для location /api/ перенаправление на backend
В начале каждой статьи добавил ссылки на другие
Спасибо, добавил!
Добавил больше информации на рис. 3.11.
Исправил рисунок 2.13
PostgreSQL всегда использовал модель многоверсионности (
MVCC—Multi-Version Concurrency Control) для управления конкурентностью транзакций. Эта модель основана на использовании снимков данных (snapshot isolation) и была реализована с самого начала. Документация PostgreSQL 7.1.Уровень изоляции по умолчанию тоже всегда был
Read Committed: документация PostgreSQL 7.1.Я немного запутал тем, что сначала начинается транзакция 2, а потом транзакция 1 (в тексте ниже это написано). Исправлю на картинке на транзакции 3 и 4 (чтобы нумерация была по порядку, как и на самом деле в Postgres).
А "фантомное чтение" тут имеется. Дело в том, что
Repeatable Readпредотвращает неповторяющиеся чтения для существующих строк, но НЕ для новых строк, которые могут быть добавлены другой транзакцией и удовлетворять условиям запроса. Что как раз изображено на рис. 2.13.С точки зрения бизнес-логики это правильно, но не с точки зрения изоляции транзакций.
Верно подмечено, исправил в тексте.
UNIQUEиEXCLUDEвызывают блокировки при проверке ограничений.Также, если одна транзакция удаляет или изменяет запись, на которую ссылается другая запись через внешний ключ, другая транзакция, которая пытается создать или изменить запись, ссылающуюся на удаляемую или изменяемую запись, может быть заблокирована. Вторая транзакция должна ждать, пока первая транзакция завершится, чтобы проверить, остается ли ссылка валидной.
Блокировки строк ещё имеют разные режимы — ссылка на документацию.
Очень много разных нюансов, которые не получается рассмотреть сразу. Может, когда-нибудь будет статья на эту тему.