В общем, я переписал на striped, конечно

striped это чёрная магия какя-то если честно.

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

поэтому без лока, в общем-то никуда

но не один же

что такое striped?

что такое striped?

Это из Гуавы

predefined array of locks

обладащий свойствами хэшмэпа

то есть для одинаковых ключей будут одинаковые локи

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

чтоб OSGi контейнеры поверх девятки могли бегать, нет?

Они итак смогут

Они итак смогут

ну вот ноют, что мол никак, или очень сложно

ну вот ноют, что мол никак, или очень сложно

Пиздаболы )

Микалай Алименков рекомендовал начинать с цифры 64 в плане дефолтного количества локов в массиве и, собссно, я ни разу эту цифру не перешагнул в плане performance

если коротко: The Java singleton is scoped by the Java class loader, the Spring singleton is scoped by the container context.

То есть, разница в первую очередь в single responsibility - обычный синглтон управляет своим циклом создания сам (кроме его реальной логики), что нарушает этот принцип, а в случае спринговых бинов - эту функцию за нас выполняет Спринг и принцип не нарушается?

Микалай Алименков рекомендовал начинать с цифры 64 в плане дефолтного количества локов в массиве и, собссно, я ни разу эту цифру не перешагнул в плане performance

Локи в массиве эт что?

Я правильно понимаю?

Локи в массиве эт что?

array предсозданных локов

то есть

Что эт

я пишу

private Striped<Lock> striped = Striped.lazyWeakLock(64);

первый раз слышу

А потом иду Lock lock = striped.get(key);

и лок/анлок

Понял, эт чтот гуавовское

То есть, разница в первую очередь в single responsibility - обычный синглтон управляет своим циклом создания сам (кроме его реальной логики), что нарушает этот принцип, а в случае спринговых бинов - эту функцию за нас выполняет Спринг и принцип не нарушается?

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

первый раз слышу

А как решаешь задачу разделения синхронизации?

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

Влет гыгы)

А как решаешь задачу разделения синхронизации?

у меня Scala future везде, без shared ресурсов

В том плане, как я описал - есть фильтр, в него валятся event-ы, надо ходить в кэш и проверить дупликацию

Влет гыгы)

ну PowerMock вроде может :)

кэш CAS не гарантирует, согласно документации

ну PowerMock вроде может :)

Да, и статики и все вот это)

ИМХО, ты или юзаешь один лок, что плохо, или пилишь что-то подобное striped типа своё

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

+ ага, понял

А зачем тебе для кэша лок?

Тем более stripped

Я просто последний раз синглтон руками писал, наверное, в ВУЗе

А зачем тебе для кэша лок?

Мне надо проверять на повторные сообщения

кэш - это такой способ сохранить информацию, что такое-то сообщение пришло

Мне надо проверять на повторные сообщения

Канкарент хэш МАП нельзя?

это не я писал, это так мне досталось

Канкарент хэш МАП нельзя?

Инстансов системы много

кэш distributed

то есть ивент может придти на один инстанс, а дубликат - на другой

Ок, тогда у тебя и лок на уровне инстанса не поможет

Скорее всего тебе нужен лок из твоего кэша

хм

я знаю, что не поможет

нужен распределенный лок

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

главное, чтобы это не было массово

Скорее всего тебе нужен лок из твоего кэша

Но вот лок из кэша - это интересная мысль

Тогда нафиг тебе лок)

счас почитаю, умеет ли он так

если не страшно

Тогда нафиг тебе лок)

лок для случая, если на один инстанс упало и изначальное и дубликат

я согласен, что это неправильно

но

распределенный случай не накрывается и сейчас

и это всех устраивает

поэтому первая задача - improve performance

то есть чтобы логически работало как сейчас, но быстрее)

ой

ERROR: S client not available

Скорее всего тебе нужен лок из твоего кэша

+ тебе в карму мил человек: http://www.ehcache.org/documentation/2.7/apis/explicitlocking.html

то, что мне надо

"and also in Distributed Ehcache"

+ тебе в карму мил человек: http://www.ehcache.org/documentation/2.7/apis/explicitlocking.html

Не факт что это будет работать быстрее

не факт

быстрее чем один лок?

а это мы померяем

я сейчас таки допишу вариант со striped

Мне кажется тебе не нужен лок, там на методе put возвращается предыдущее значение ж? Достаточно его на null проверить

Мне кажется тебе не нужен лок, там на методе put возвращается предыдущее значение ж? Достаточно его на null проверить

а если в этот момент другой поток пут сделал?

этот пут же не атомарный, насколько я понимаю

а если в этот момент другой поток пут сделал?

скорее всего в рамках одного хоста видимость будет, но эт не точно

скорее всего в рамках одного хоста видимость будет, но эт не точно

вот

я джавадок почитал - там атомик никто не гарантирует

поэтому, похоже, возможен вариант, когда оба потока вернут null

по коду там лок на key делается

так что атомарный

эт я про BlockingCache

да

вижу

BlockingCache

счас проверим, какой у нас бэкенд

счас проверим, какой у нас бэкенд

выкинь вообще и возьми hazelcast)

выкинь вообще и возьми hazelcast)

ну э

я немного не в той должности, чтобы такое делать)

я слегка просто "эксперт", а не "лид")

мда

нельзя просто так blockingcache

надо писать свою cachedecoratorfactory

которая будет генерить не просто кэш, а блокирующий

в моем случае проще striped - сильно меньше затрат

в моем случае проще striped - сильно меньше затрат

Ты проверь, может он из коробки без блокинга работает