Одновременные сообщения и чтения канала - пропущенные записи при переходе от головки канала к более новым записям
Это классический параллельный вызов чтения и записи:
Мы публикуем записи в фиде Atom Hopper в базе данных Oracle через Hibernate, и наш партнер их читает. Если мы публикуем записи с 1 по 5, то 5 является главой (то есть последней опубликованной). Наш партнер запрашивает страницу канала, начиная с записи 1, и получает записи 1-5. В следующий раз, когда они спросят, они будут запрашивать записи, более новые, чем запись 5. Клиент отслеживает, какие записи были прочитаны.
Проблема в том, что, пока они читают, мы публикуем запись с номером 6, которая получает немного более старую отметку времени, чем цифра 5, в столбце "создан". Поскольку это было совершено после прочтения, наш партнер никогда не получает номер. 6. Они получают 7, 8 и 9, которые мы опубликовали за это время, все с более новыми временными метками, чем nr. 5.
Так как же избежать пропущенных записей, таких как nr. 6? Мы позволяем базе данных установить метку времени в качестве первой меры, но все еще есть вероятность, что мы можем зафиксировать "более старую" запись во время их чтения, поскольку между моментами, когда записи получают метку времени, и когда она фиксируется, время, которое нельзя пренебречь, Можно ли заблокировать страницу базы данных для чтения или что-то?
Я думаю, что нам, возможно, придется изменить поведение клиента, то есть запросить записи более новые, чем, скажем, номер 4, если между ними произошел коммит. Было бы лучше использовать последовательности вместо меток времени с точки зрения перехвата коммитов, таких как nr. 6?