Сервис singleton — см. исходники. В случае использования scope prototype синхронизироваться по this действительно нельзя.
И скоро вместо протухания вы получите снижение производительности и как финал OutOfMemory
Согласен, данное решение на практике неприменимо.
Не работает в кластере
Да, я об этом указал в статье: «решения 1-3 вполне подойдут для небольших одноинстансных сервисов».
Лочить по сети N нод для каждого getUserById()
Блокировка будет не на каждый getUserById, а только на операцию создания Client и блокироваться будут только запросы конкретного клиента.
Решение 0 Единственно правильное
Если задача именно решить проблему со вставкой, то вполне можно использовать Ваш вариант. Основная цель статьи больше показать способы синхронизации запросов, возможно просто пример с integrity constraint violation не самый подходящий, так как эта проблема имеет решения и без синхронизации.
Если синхронизироваться на сессиях, то есть еще такой неприятный момент — когда на api прилетит первая пачка запросов от одного клиента, они должны все «получить» одну сессию. Для того, чтобы это сделать, нужен специальный метод, который вызывается клиентом первым и который создает сессию, а далее остальные методы просто уже использую ее идентификатор. В приложениях с явной авторизацией этот метод всегда есть — это собственно метод авторизации. Если в приложении нет авторизации или она проходит один раз, а не при каждом старте, заставлять клиент сначала создать на сервере сессию, а только потом запрашивать бизнес методы приведет к увеличению времени запуска приложения.
Сколько точно съедает сейчас уже, к сожалению, не припомню, но было в допустимых пределах. Наибольшая трудоемкость была не при работе с базой как таковой, а в обращении в сторонние сервисы в ходе создания
Действительно можно сделать так, а если реализация репозитория делается в ручную, то можно при insert использовать конструкции вида «ON CONFLICT» / «ON DUPLICATE KEY». Единственное, при данном подходе будет кратно больше запросов к БД, что не всегда хорошо на нагруженных сервисах. Но конкретно в нашей ситуации мы пошли в сторону синхронизации даже не по этому — проблемным местом в создании сущности Client являлась необходимость обращения к нескольким другим сервисам до коммита, и без синхронизации мы бы порождали дополнительную нагрузку еще и на нах.
«При старте клиентское приложение асинхронно отправляет «пачку» запросов к API» — это ситуация, когда авторизация уже пройдена или вообще отсутсвует.
В примерах Client — это сущность устройства пользователя, оно может меняться при тех же учетных данных.
@Slf4j на сколько я помню создает логгер по названию класса, а если необходимо создавать по имени — то не подойдет. Другой вопрос кому как удобнее получать логгер — по классу или по имени, лично у меня есть примеры когда в одних случаях удобнее первый подход, есть когда второй — тут вопрос как личных предпочтений так и зависимости от контекста конкретной задачи =)
Согласен с вами, попытаюсь оправдаться тем, что не имел возможности во многих местах углубиться, в том числе и про новые подходы с поставщиками и на сколько они разгружают garbage collector и прочее, ибо статья и так получилась весьма объемной.
Начиная с версии 1.6, если не найдена ни одна реализация, то произойдет переключение на режим «no operation», но работать будет! Это написано в руководстве, второй абзац.
Да совершенно верно, там написано: " If no binding is found on the class path, then SLF4J will default to a no-operation implementation", но мной имелось ввиду несколько другое, что в таком случае должна быть подключена slf4j-nop-1.*.*.jar, собственно реализация заглушки.
Кеш первого уровня всегда привязан к объекту сессии, а следовательно при параллельных запросах не поможет никак.
Сервис singleton — см. исходники. В случае использования scope prototype синхронизироваться по this действительно нельзя.
Согласен, данное решение на практике неприменимо.
Да, я об этом указал в статье: «решения 1-3 вполне подойдут для небольших одноинстансных сервисов».
Блокировка будет не на каждый getUserById, а только на операцию создания Client и блокироваться будут только запросы конкретного клиента.
Если задача именно решить проблему со вставкой, то вполне можно использовать Ваш вариант. Основная цель статьи больше показать способы синхронизации запросов, возможно просто пример с integrity constraint violation не самый подходящий, так как эта проблема имеет решения и без синхронизации.
В примерах Client — это сущность устройства пользователя, оно может меняться при тех же учетных данных.
Одной из целей статьи было показать пример работы с каждым из указанных фреймворков, как показать работу Logback без Slf4j?
буду рад услышать аргументы
Не могу с вами согласиться, ибо не могу назвать устаревшим log4j2, да JUL в 8 версии расширил немного функционал
Согласен с вами, попытаюсь оправдаться тем, что не имел возможности во многих местах углубиться, в том числе и про новые подходы с поставщиками и на сколько они разгружают garbage collector и прочее, ибо статья и так получилась весьма объемной.
Да совершенно верно, там написано: " If no binding is found on the class path, then SLF4J will default to a no-operation implementation", но мной имелось ввиду несколько другое, что в таком случае должна быть подключена slf4j-nop-1.*.*.jar, собственно реализация заглушки.