Здравствуйте, afkos, Вы писали:
A>С table-level update lock мы фактически ограним число одновременно выполняющихся (изменяющих) транзакций до 1, увы, это не приемлимо в нашем случае.
Спасибо за подробный и обоснованный ответ. Ок, неприемлемо так неприемлемо.
A>Спасибо, ознакомился
A>Мы не можем использовать специфичные механизмы СУБД, т.к. поддерживаем сразу несколько СУБД: SQLServer, PostgreSql, Oracle, но полезно разобраться как там решаются те же проблемы.
Ок, ясно.
A>Вот что я выяснил:
A>Любопытно, что изменения сделанные в транзакции, не видны через CHANGETABLE даже внутри этой самой транзакции, что наталкивает на мысль, что номер версии таблицы увеличивается не в момент изменения, а в момент фиксации транзакции.
Да, это очевидное решение задачи упорядочивания изменений. К сожалению, я не вижу другого способа, при котором лог будет отштампован в порядке завершения транзакций, а не в порядке их начала
.
Я даже не вижу способа сделать это в рамках прикладного кода, за пределами ядра СУБД.
A>Пока что пришел к нескольким решениям:
Ограничить бесконтрольное разрастание можно
а) регулярно обрезая все логи по таймстампу — например, всё, что старше 48 часов. Клиент, который пришёл позже, обязан начать синхронизацию "с нуля".
б) либо регулярно прибивая сами подписки, если за ними долго не приходят.
A>Буду рад новым идеям
