Это я конечно схематично показал, самому смешно стало. Делается через курсор, и Max TIMESTAMP находится в процессе обработки.

tanglirа если транзакция 1 уже открыта, но ещё не успела изменить данные?

Тогда блокировки еще нет, и селект отрабатывает. Но и timestamp после коммита трансакции 1 будет больше, чем максимальный в данных селекта. Изменения, которые сделала транзакция 1 будут замечены в следующей репликации.

Dimitry SibiryakovПисатели не блокируют читателей.


Вообще зависит от TRANSACTION ISOLATION LEVEL. READ COMMITED блокирует измененные записи на чтение, пока не произведен COMMIT

Dimitry SibiryakovКакой-то это неправильный READ COMMITTED. Это скорее NOREAD COMMITTED...


Меня помнится тоже поначалу удивляло :) Но вообще логично - "читать закоммитенные данные". Т.е. не закоммитенные не читаются.

sphinx_mvА если до коммита 1-ой (все-таки меняющей данные) транзакции пройдет коммит еще надцати других меняющих и реплицирующих транзакций?
НЕ РАБОТАЕТ!
Кроме клинического случая с "грязным чтением".

1. SELECT на репликацию проходит только если нет открытых трансакций с измененными данными.
2. Max(timestamp) SELECTа на репликацию сохраняется локально на клиенте, который делает репликацию.
3. Любые изменения после прохождения SELECTа на репликацию (неважно от скольких трансакций) имеют как следствие увеличение timestamp по сревнению с полученным SELECTом на репликацию Max(timestamp). И поэтому отлавливаются следующей репликацией.
4. РАБОТАЕТ! уже больше 3 лет :)

sphinx_mv1. И кто же его запретит сделать? И как Вы узнаете, что открытые транзакции не успели изменили данные после момента любой такой проверки?


Как вам правильно написали, сервер сам не даст сделать SELECT, если существуют открытые трансакции с измененными данными.
SET TRANSACTION ISOLATION LEVEL READ COMMITED в коннекте на репликацию, и SELECT ждет коммита на измененные данные. Это блокировка на чтение измененных и незакоммиченых данных. Речь идет о MS SQL Server, если что.


sphinx_mv2. timestamp фиксируется в исходной таблице по UPDATE, а не по COMMIT. Если на сервере больше одного "пишушего" коннекта, НИКТО не гарантирует, что они коммитятся именно в порядке нарастания timestamp. И соответственно, совершенно никакой гарантии что именно в порядке нарастания timestamp данные будут реплицированы на получателя.


нас в данном случае совершенно не интересует порядок UPDATE и COMMIT, которые будут произведенв после SELECTа на репликацию. Потому что см. выше - нет измененных данных без коммита на момент SELECTa.


sphinx_mv3. Ваш MAX(timestamp) на получателе НЕ ВИДИТ timestamp незакоммиченных и тем более не прореплицированных записей из исходной базы данных. Из п.2. напрямую следует НАРУШЕНИЕ порядка нарастания значения MAX(timestamp) на основе данных получателя.


еще раз - нет измененных данных без коммита на момент SELECTa. Все timestamp на момент SELECTа актуальные - или закоммитенные, или без изменения с момента открытия трансакции. Все что случится после SELECTa приведет к увеличению timestamp по сравнению с полученным SELECTом.


sphinx_mv4. Без блокировок ТАБЛИЧНОГО уровня для пишуших транзакций - НЕ РАБОТАЕТ. Даже для серверов-"блокировочников".
Либо у Вас система НЕ-МНОГОПОЛЬЗОВАТЕЛЬСКАЯ.


Блокировок ТАБЛИЧНОГО уровня нет, есть блокировка на чтение измененных записей в трансакции. Система многопользовательская, в среднем около 10 пользователей единомоментно непосредственно работают на сервере и около 100 клиентов с локальными копиями, каждый раз в пару дней делает репликации. База небольшая, как я уже писал.

sphinx_mvИ даже этот самый строгий уровень изоляции не гарантирует, что будут заблокированы ВСЕ записи в таблице - актуально для запросов с критериями отбора (как в обсуждаемом случае). Соотвественно на непересекающихся наборах записей одновременные транзации вполне себе могут ужиться, не мешая друг другу...



Кстати тут как раз все "чисто". Критерий в SELECTе один - на timestamp, а он меняется гарантированно при любом изменении записи. И SELECT попадает на блокировку.

дополнение: Критерий в SELECTе один - на timestamp, а он меняется гарантированно при любом изменении записи так, что измененная запись попадает в выбоку SELECTа . И SELECT попадает на блокировку.

В больших таблицах проиндексированно. Сейчас заглянул в лог репликации, последние 2 длительность:

начало репл. конец репл.
25.05.2012 12:10:36 25.05.2012 12:15:51
25.05.2012 11:36:07 25.05.2012 11:47:10


база 1,5 гига. Так что мне кажется неплохо 5-10 мин. С учетом того, что интернет у client через мобильную связь. Это было кстати условием - короткая репликация с плохой связью.

Dimitry Sibiryakov
1. Репликационный запрос читает первую страницу из трёх
2. На второй он останавливается, ожидая окончания параллельного апдейта
3. Апдейт записи на первой странице
4. Апдейт записи на третьей странице
5. Вторая страница освобождается, запрос получает timestamp из записи на третьей странице,
который больше чем у записи из п.3 на первой. Запись с первой страницы выпадает из поля
зрения.

При наличии индекса, такое, вроде бы, невозможно.


Хм.. Теоретически наверно это возможно. Хотя с моей точки зрения это был бы баг в SQL Server. Надо будет прошерстить таблицы. Я давно в эту базу не заглядывал, не было поводов.