99
каждый раз надо тащить с бд один объект - проверить значение его поля - при выполнении условия обновить это поле и обновить запись в бд. И надо учитывать, что выполнение условия при текущем пакете зависит от обновленного значения при предыдущем пакете.
Что происходит на деле
1. приходит первый пакет - тащит с бд объект
2. обновляет значение поля - отправляет на апдейт в бд
3. в этот момент приходит след пакет и тащит с бд объект, который еще не успел обновиться после первого пакета - то есть значение там еще старое и получается несостыковка значений
предполагаю, что полученные пакеты нужно кещировать - дальше запускать метод, который по одному будет брать пакет из кеща - подождет пока обновится в бд и только потом из кеща брать след пакет.
Что-то внутри подсказывает, что мне тут надо использовать async await - channels - actor - в одном наборе.
В правильном направлении иду? и если знаете какой-то похожий пример или статью в этом духе - подскажите пожалуйста
Все сложно (c) Стоит задача синхронизации, которая в общем случае не очень хорошо решается. Но решается неплохо в частном случае, например: 0. Несколько инстансов, база без локов - распределенный консенсус - отдельная система типо etcd/zookeeper которая будет отвечать за локи 1. Несколько инстансов приложения, один postgres - лок на запись aka select for update 2. Один инстанс - actor отлично подойдет, вот тут про опции можно прочитать https://kotlinlang.org/docs/reference/coroutines/shared-mutable-state-and-concurrency.html
😁 я один момент не указал, ссори. это все на андроиде - инстанс один, спасибо за наводку, пойду копаться
телеграм подобным образом накатывает обновления в базу
Имхо. Кэширование записи из бд в памяти и получить из вебсокета flow, чтобы обрабатывать в порядке очереди. Не подойдёт, если пакеты идут кучей постоянно, и в этом случае придется все равно часть отбрасывать.
Я бы начал с обычной пессимистичной блокировки. Если есть нужда освободить поток чтения из сокета, тогда через очередь.
Обсуждают сегодня