всё равно нужен лок
а помогает этот подход когда есть читающая транзакция
В "классической" реализации — да, не помогает (и да, там всё равно нужен lock).
спасибо! я признаю: изначально криво задал вопрос
а как тогда это происходит с двумя пишущими операциями/транзакцими (вот тут поправьте)? каждая пишет в свою версию оптимистично, потом одна выигрывает а другая откатывается чтоб заретраить? или прям честный лок
> каждая пишет в свою версию оптимистично Нет, locks накладываются перед записью. В обычных MVCC-реализациях RR первая получает lock, а вторая ждёт. Если первая успешно завершилась, то вторая откатывается. > или прям честный лок Т.е. прям да. :)
зачем второй откатываться? почему ей не дождаться освобождения лока и потом выполнять свои инструкции? или это из-за RR?
Потому что таким образом гарантии RR будут нарушены (т.е. да, это из-за него).
а в случае RC? откатов не будет? подобных
Это уже зависит от реализации RC (я не знаю всех, разумеется). В PostgreSQL — почти никогда не будет, например.
будет ожидание, а потом выполнение (при получении лока), верно?
Обсуждают сегодня