Всем привет, подскажите пожалуйста, правильно ли я понимаю Когда у нас

транзакция с isolation level = REPEATABLE READ, то блокировка на чтение держится всю транзакцию
То есть, если я начинаю транзакцию, вызываю select, а потом update (на ту же строку), то в теории должна произойти ошибка (т.к. update не может получить лок из-за уже существующей блокировки на чтение)?

Какая СУБД?

я слышал, что это зависит от СУБД, но настолько? конкретно в моем примере это MySQL (InnoDB)

Да, настолько. К примеру, PostgreSQL (да и любой чистый "версионник") на чтение не блокирует ничего и никогда, например. :) А про MySQL не знаю... были какие-то чаты именно по нему — может, стоит поискать / спросить и там тоже?

Если в общем, то неправильно. Если по MySQL - тоже.

понял, спасибо)

В innodb ровно такой же mvcc, как в PG

почему, если не секрет, в общем неправильно?

А в конце ты вообще бред написал. Как это не получит, если это одна и та же транзакция?

В общем механизмы обеспечения ACID транзакций и isolation у всех СУБД разные

то есть одна и та же транзакция внутри себя может менять уровень блокировки?

Хмм... мне почему-то казалось, что они там что-то дополнительно блокируют на RR. Вот, собственно: REPEATABLE READ This is the default isolation level for InnoDB. Consistent reads within the same transaction read the snapshot established by the first read. This means that if you issue several plain (nonlocking) SELECT statements within the same transaction, these SELECT statements are consistent also with respect to each other. See Section 15.7.2.3, “Consistent Nonlocking Reads”. For locking reads (SELECT with FOR UPDATE or FOR SHARE), UPDATE, and DELETE statements, locking depends on whether the statement uses a unique index with a unique search condition, or a range-type search condition. For a unique index with a unique search condition, InnoDB locks only the index record found, not the gap before it. For other search conditions, InnoDB locks the index range scanned, using gap locks or next-key locks to block insertions by other sessions into the gaps covered by the range. Последнего пункта на RR в PostgreSQL просто нет, например.

Вон как выше Ярослав написал, некоторые вообще ничего при чтении не блокируют

Конечно

Предикаты на ключах могут

Транзакции сами себя не блокируют, кажется, нигде (это было бы глупо, нет?).

Подожди, на RR же фантомы могут быть?

По ISO SQL — да, могут.