Я ищу решение для сценария краевого случая, когда клиент постоянно спрашивает сервер о том, что нового не удастся из-за временных меток.
В этом примере я не использую порядковые номера из-за проблемы с другим краевым случаем. Вы можете увидеть эту проблему здесь: Клиент идет на сервер и спрашивает" Что нового? " - Проблемы с порядковыми номерами
Предположим, что мы используем временные метки. Каждое обновление строки добавляет метку времени сервера. Клиенты постоянно спрашивают, что нового, начиная с отметки времени последнего элемента, который они получили. Просто? Да, но...
Сбой сценария:
Времена ниже являются произвольными для удобочитаемости. Предположим, что миллисекунды в реальном мире.
2:50 Client C checks for updates.
2:59 Client A starts update on a row. (Sets lastModified to 2:59)
2:59 Client B starts update on a row. (Sets lastModified to 2:59)
3:00 Client A Row update becomes visible on DB. (lastModified still at 2:59)
3:00 Client C checks for updates >2:50. Get’s A’s update. Good.
3:01 Client B Row update becomes visible on DB. (lastModified still at 2:59)
3:10 Client C checks for updates >2:59. Gets nothing. Misses B update. Bad.
Это предполагает, что lastModified не может быть установлен атомарно, и может быть задержка между настройкой, и строка становится доступной в базе данных. Если база данных была отложена, эта задержка может быть намного больше.
Мы можем установить проверку на обновление для произвольного запроса на раннее время, вызвав перекрытие. Это неэффективно из-за возможного дублирования данных, но не фатальных. Однако можно ли узнать, сколько перекрытий необходимо для всех случаев? Может ли зависшая база данных редко задерживать отображение обновления за секунды? Минуты?
Когда клиенты спрашивают, "что нового" неоднократно кажется обычным случаем, и я нахожу удивительным, чтобы не находить лучшего богатства лучших практик в этом вопросе.
Любые идеи по решению этого сценария или рекомендации лучшего, желательно платформенного агностика, решения для запроса изменений?