tengiz wrote:vc - во-первых, я полагаю, что Ваше возражение не по существу. Исходные транзакции можно переписать иначе, например вот так:
if (select count (*) from t1 where col < 0) = 0 then update t set col = -col where col = 1
But the re-write does not change the fact that every row (the entire table) would have to be inspected and threfore locked without any need for an additional mechanism such as predicate locking. Your new SQL is fully equivalent to the original one in terms of transaction history conflicts.
tengiz wrote: Предикатная блокировка не зависит от наличия или отсутствия реальных данных. Поэтому "predicate locking would have to lock *potential* not real rows" - это тавтология. Предикатная блокировка по определениею блокирует предикат, на основе которого делается доступ к данным вне зависимости от наличия или отсутствия удовлетворяющих предикату данных.
I fully agree with the above. My point (which you are disputing) is that predicate locking is not needed *if* the database is static, 2PL with its locking *existing* data woud be enough. Predicate locking was 'invented' precisely to handle insert/delete phantoms.
tengiz wrote:A history with any permutation of all the reads preceding the writes would deadlock, therefore, for your example, 2PL alone would be sufficient. In other words, locking the existing data is enough to ensure serializability which is a subtle but crucial difference from the phantom inserts/deletes...
Нет, неверно.
I am not sure what part of my statement you consider incorrect. Could you please clarify ?
tengiz wrote: Ровно та же самая техника (блокировка целой таблицы) позволяет избежать фантомов в случае insert/delete. В любом случае нужно как-то учитывать данные, которые не удовлетворяют условиям отбора сейчас, но могут удовлетворять позже. Поэтому если мы разрешаем использовать табличные блокировки (а они по сути нужны только тогда, когда нет предикатных блокировок реализованных любым способом), то никакой разницы между insert/delete или update нет.
It's true that predicate locking (or its implemented subsets) are enough to ensure serializability but again that's not the point I was trying to make. I believe I showed that the example you presented can be handled by a 2PL scheduler without need for predicate locking of any kind. If you think it's not so, please show where the mistake is.