Смотрите господа и товарищи
Есть таблица и есть желание получать из нее количество записей- назовем ето счетчиком

собственно выглядит все просто - берем селект каунт и записываем значение в дто
но каждый раз делать такие селекты я не хочу ,поэтому я кеширую этот счетчик
и тут вопрос нужна ли тут тред сейф коллекция - concurrentHashMap,если значение все равно выгребается из бд,а как я понимаю на стороне бд с тред сейвом все норм .Счетчик инвалидируется при новой записи/удалении,но как я понял из документации метод put все равно будет не синхронизирован и два потока смогут теоретически записать в какой то момент одинаковые ключи
поэтому вопрос философский тут больше - наверно все таки тред сейф колекция тут будет бесполезна без synhronized блоков

стоит отметить что этот метод дергается контроллером - контроллер обычный ,не реактивный.

да,это грубо говоря группа - а счетчик - количество человек в ней.А групп там много и на каждую нужно отображать текущее количество человек в ней.

Я чо то не оддуплил как тут @Cacheble прикрутить ,но я пытался ,щас попробую еще раз)

так как источником правды у нас является бд,то товаров будет -10
транзакции работают правильно и с этим все норм ,меня интересует лишь вопрос какую мапу использовать
конкуретную - но в ней один хрен пут/гет не конкурентны
либо обычную

почему же велосипед? вполне себе нормальная практика- зачем мне ,если я точно знаю,что состояние не менялось - делать лишний запрос в бд- это дорого очень
кеширование тут само собой напрашивается ,вопрос лишь в реализации

петро ты опять не прочитал тему- счетки идут на группы в которых есть люди) групп много ,соотвественно ключом мапы является id группы,значением счетчик

так чтобы он не протухал его надо инвалидировать при инсерт/делете

состояние меняется при каждой транзакции- если был апдейт/делит ,ты верно уловил направление - но эти инсерты делаются батчем в рамках одной транзакции - тоесть если накинули 1 к - то и счетчки вырастет на 1к
и на методах инсерта /делета у меня этот кеш инвалидируется - так что тут все в порядке

не тормоза мне не нужны- с мапой все работает супер быстро ,тут вопрос лишь в конкуретности ,сейчас у меня там конкарент мапа- я думаю нужна ли она мне ,если верить докам некторые из ее методов не трейд сейф,хотя работает она так же быстро ,как и обычная мапа

как раз и не протухает и доступ конкуретный
но запись неконкурента
я не хочу тащить в код синхронайзед блоки

у нас хелелькаст на проекте ,но не хочу туда простой счетчик писать - я думаю что для этого подойдет именно хешмапа - самое дешевое и быстрое решение

я ж тебе ответил на методах инсерта /делита кеш инвалидируется
тоесть я заново делают селект каунт и пучу это в мапу - перезаписывая текущее значение
но надо понимать что такие манипуляции у нас достаточно редки ,в основном идет запрос на получение и вот тут кеш и будет работать

что то на подобии,но админов может быть много ,в том числе инсерты могут быть по внешним каналам типо кафки

писать то можно,бд это сама разрулит,моя мысль в том,чтобы счетчик был всегда актуальным и собственно я наверно воткну @Cashable
в имлетментации хезель кастовской - работает молниесно - и конкуретность блюдется)

вадян ну ты хоть бы думал прежде чем отвечать
как по твоему что дешевле из кеша достать или из бд?
следуя твоей логике кеш вообще не нужен - ведь бд для того и создана да?)

да я вообщем хезелькаст наш прикрутил,самое норм решение оказалось ,так как нод то у нас много и соотвествено локальный кеш совсем не подходит,а нужно распределенное решение ,чем собственно хезелькаст и является.