Тегну вас еще)) А то Николай не видит)) двухвазная блокировка же не защищает от “фантомного чтения” (phantom reads), которого нет в SERIALIZABLE, значит двухфазная блокировка вполне применяться может для достижения REPEATABLE READ. Или я что-то путаю?

СУБД не важна. В 2PL блокировки все отпускаются только в конце транзакции. А в SI берется shared на таблицу только в момент чтения данных из нее и после сразуже отпускается. вот например, если есть 2 селекта внутри одной транзакции, то если это SI , то сначала взмется shared на одну таблицу. из нее прочитаются данные. блокировка отпустится. Дальше возмется блокировка на 2ю таблицу и считается данные из нее . после этого shared блокировка сразу отпустится. А если это 2PL, то блокировка shared даже на первую таблицу будет держатся, когда из нее уже все прочитали. Согласны?

Защищает, если блокировать то, что нужно.
Да, Вы что-то с чем-то путаете. ;)
2PL — это просто принцип, т.е. в первой фазе блокировки только накладываются, во второй — только отпускаются.

т.е в других уровнях изоляции тоже используются блокировки, но это не 2PL, а 2PL = это собый подход, когда есть 2 фазы - набор блокировок ( и тут ни одна из них не релищится) и вторая фаза - где ВСЕ блокировки релизятся

Ну да, но вы не можете заблокировать данные, которых еще в этой транзакции не запросили 😅 А значит не защищает))

фантомные чтения не возможны. т.е если транзакция прочитала таблицу, то на ней будет лок shared и никто в нее не вставит, пока транзакция , которая прочитала не завершится

а будет ли лок на всю таблицу, или же только на те данные, которые были прочитаны, нигде же не описан принцип, как нужно лочить при двухфазной блокировке)

да, shared lock будет на всю таблицу

> СУБД не важна.

А, т.е. Вы ответа на свой вопрос не знаете, но уже откуда-то знаете, что СУБД не важна? ;)

> А в SI берется shared на таблицу только в момент чтения данных из нее и после сразуже отпускается.

В PostgreSQL (MVCC), например (раз "СУБД не важна") никакого shared lock на данные не берётся. А вот lock на таблицу сохраняется до  конца транзакции.

> Согласны?

Нет, не согласен. И факты не согласны. Более того, в упомянутом PostgreSQL никаких "обычных" блокировок SERIALIZABLE по сравнению с другими уровнями не добавляет. И, кстати, RR не берёт никаких дополнительных блокировок по сравнению с RC.

Странно, а всех защищает. ;) Откройте любой учебник или документацию любой СУБД-"блокировочника".

Кому интересно. Вот тут написанно хорохо. можно по разному локи эти называть. Не в этом суть. Главное, что  есть Read-lock и Write-lock . https://en.wikipedia.org/wiki/Two-phase_locking

Где Вы нашли настолько "прекрасную" СУБД, ради любопытства? ;)
Т.е. о какой речь, если не секрет?

Не важна СУБД. 2PL это принцип. Вот и вики они без СУБД рассматриваю. Пишут так "A read-lock blocks an intended write by another transaction by blocking the respective write-lock."

В каждом "фундаментальном" учебнике подробно описан этот принцип, just FYI.

"A write-lock blocks an intended (already requested/issued) read by another transaction by blocking the respective read-lock ."

Нет, СУБД важна. 2PL — это принцип, да. Он используется почти всегда (как пример, MS SQL на RC нарушает его, отпуская блокировки (на чтение) записей сразу в первой фазе).

И из этого принципа никак не следует, что для достижения уровня изоляции SNAPSHOT кто-то должен делать такие глупости, как "то на ней будет лок shared и никто в нее не вставит". ;)

"two-phase locking (2PL) is a concurrency control method that guarantees serializability". Т.е это способ получить serializability, а для SI он не нужен.

Понял, был не прав на счет фантомного чтения!) Спасибо что помогли разобраться)

да, в SI не нужен лок на таблицу при чтении.

В другой транзакции:

DROP TABLE <the_one_your_transaction_read>;

И как Вы гарантируете repeatable reads, а?