Для обеспечения последовательности событий без использования блокировок и сериализации транзакций, как можно избежать проблемы пропуска EventNumber = 1 в описанном сценарии?
Одним из способов обеспечения постепенного увеличения значения поля при одновременных транзакциях с минимальной задержкой может быть использование оптимистической блокировки. При таком подходе все транзакции могут одновременно изменять значение поля, но перед сохранением данных проверяется, не было ли изменений с момента начала транзакции. Если данные изменились, то транзакция отклоняется и ее необходимо повторить. Для избежания пропуска EventNumber = 1 можно использовать механизм проверки условия при обновлении данных. Например, перед изменением поля EventNumber можно проверить, что текущее значение равно ожидаемому значению (например, EventNumber = текущее значение + 1). В случае, если текущее значение не соответствует ожидаемому, транзакция должна быть отклонена или повторена. Таким образом, с использованием оптимистической блокировки и проверки условий можно обеспечить постепенное увеличение значения поля и избежать проблемы пропуска EventNumber = 1 при одновременных транзакциях.
Параллелизм и последовательность - это две противоречивые постановки. Тебе стоит
пересмотреть подход к разработке. Подумай насколько важен для тебя LastEventNumber
как объект наблюдения человеком. Если он меняется чаще чем 10 раз в секунду то
вряд-ли он имеет смысл для публикации.
В паралелльных системах для массовой загрузки например объекты продюсеры захватывают
диапазоны номеров. Диапазо берется из объекта SEQUENCE. Умножатеся допутим на 10000 .
И получается что перый продюсер захватил номера с 1 до 10000 . Второй - захватит с 10001
до 20000 и так далее.
Да у тебя не будет строгой последовательности но вопросы коллизий ключкей и performance
будут решены сразу и не будет issues в будущем.
А почему транзакция? Или они неявные? Инсерт должен быть атомарным или все таки итерирование сиквенса и следующая вставка не атомарны?
В любом случае, вы решаете не ту задачу. Если идет гонка, значит события одномоменты и нам должно быть без разницы в каком порядке они отработают. Но, раз это важно, значит эти события зависимы, если так, то манипуляции с вставкой не помогут, сегодня вы победите порядок коммитов, а завтра будет гонка при получении сиквенса и тут уже ничего не сделаешь. Зависимые события должны обрабатываться последовательно в одном потоке, т.е. в вашем случае их должен обрабатывать один продюсер, иначе никак, если даже сегодня заработает, то завтра малейшая флуктуация поменяет порядок. Как альтернатива вы можете построить сложную логику проверки зависимостей, но контролировать такой код будет гораздо сложнее.