@guga4ka immutables.org - вещь! Спасибо сейчас рекомендацию

@guga4ka immutables.org - вещь! Спасибо сейчас рекомендацию

404

404

https://immutables.github.io

https://immutables.github.io

да , так видно, спс

Народ, как прикрутить секурити к spring web service?

Народ, как прикрутить секурити к spring web service?

java.security.* ?

java.security.* ?

в проекте SpringBoot есть Spring Web в связке со Spring Security. Есть ли возможность через те же AuthenticationManagerBuilder и HttpSecurity сделать авторизацию к Web Service?

Ой, это не подскажу.

Думала хотите права модулям ограничить

Думала хотите права модулям ограничить

в идеале - к урлам WS по той же логике... если нет - то тот же custom UserService прикрутить... ну чтоб по той же схеме и те же юзвери с паролями ходили

Народ. Кто поможет. Есть сервер который принимает огромное колличество запросов. Для каждого запроса нужно сходить в базу, достать записи удовлетворяющие условию, взять одну запись самую старую и вернуть клиенту. Тоесть каждый реквест должен схватить строку в бд и остальные запросы не должны ее уже видеть. Попробовали select for update чтобы типо сделал селект и заблокировал строку и никто ее не изменит пока не комитнешь. Но следующий запрос выполняет такой же селект и получает заблокированую строку. Кароче не работает. И вообще решение с селект фор апдейт не очень. Как можно такую задачу решить другими способами?

элементарно, заведи поле "взял в работу", по умолчанию 0 и делай update table set field = id where field = 0 + самое старое, потом селектишь его

но это не про жаву

С jpa такое прокатит?

Тоесть ты предлагаешь сначало обновить. А потом заселектить?

+1 предлагает колонку с маяком

разбить задачу на две задачи

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

сначала зарезервировать, потом выбрать

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

Можно написать процедуру в бд

Есть в таблице юзерс 50 юзеров с именем вася. Мне приходит 30 запросов - дай мне васю. Я должен каждому дать по одному васе.

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

Народ. Кто поможет. Есть сервер который принимает огромное колличество запросов. Для каждого запроса нужно сходить в базу, достать записи удовлетворяющие условию, взять одну запись самую старую и вернуть клиенту. Тоесть каждый реквест должен схватить строку в бд и остальные запросы не должны ее уже видеть. Попробовали select for update чтобы типо сделал селект и заблокировал строку и никто ее не изменит пока не комитнешь. Но следующий запрос выполняет такой же селект и получает заблокированую строку. Кароче не работает. И вообще решение с селект фор апдейт не очень. Как можно такую задачу решить другими способами?

получается взять записи по условию + не «взята в работу», ордер по дате по убыванию, берешь последнюю, ей сеттаешь флаг «в работе» и возвращаешь клиенту

вторая задача - ээто лок записи - как сказали делать update - update как рпаз делает лок

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

Мне приходит 30 запросов. В первом запросе я делаю селект с условиями и получаю 1 запись. Но остальные 29 запросов делают такой же селект и получают эту же запись. Все 30 запросов прихолят одновременно

Они может и приходят одновременно , но обрабатываются по очереди

вот пример с процедуркой ...

Они может и приходят одновременно , но обрабатываются по очереди

вообще не)

зависит от уровня изоляции бд

+ блокировки в жпа

Второй селект достает ту же строку до того как первый успел комитнуть

Второй селект достает ту же строку до того как первый успел комитнуть

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

+ блокировки в жпа

Делал пессимистик врайт но он блочит все

Не дает втрому запросу ничего

Апдейт залочит строку и дабл селекта не будет

на jpa - такое делается через lock

на jpa - такое делается через lock

Говорю же делал локи

Не так как ожидается работают

Делал нетив квери и skip lock

Тоже не помогает

пример кода есть? как вы делает лок

Говорю же делал локи

как делал?

@Lok с lokmode разными. Пессимистик рид врайт и тд

?

что за аннотация такая

В спринг дата

Ща в метро сяду подробней опишу

entityManager.lock(entity, LockModeType.PESSIMISTIC_WRITE)

вот так апи выглядит блокировки

и это то, что нужно в твоем сценарии

пока не закоммитишь,никто не запишет и не прочитает

https://www.baeldung.com/jpa-optimistic-locking

про таймают нукжно паомнить - а то нода упадет итд

https://www.baeldung.com/jpa-optimistic-locking

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

https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/TransactionJTA_Overview-Pessimistic_and_optimistic_locking.html

Есть контроллер. В него приходит реквест. Контроллер дергает метод сервиса в который передает поле например имя. В сервисе метод помечен @Transactional и внутри дергает метод репозитория потом деоает задержку в 5 сек. В репозитории начинаются жксперементы. 1. @Lock(LockModeType.PESSIMISTICK_WRITE) findTop1By..... В джиметре создается 5 потоков которые кидают один и тот же реквест одновременно. Результат - выполняется первый запрос. 5 секунт отрабатывает, начинает выполняться второй запрос и тд. 2 . Переписывается на netivQuery где пишется select for update skip lock. Результат в джиметре - первый поток блокирует на 5 сек базу. Остальные 4 отваливаются так как пытаются получить доступ к этой же записи. Через 5 сек первый отрабатывает успешно

начни с простого - напиши процедурку plsql и вызывайте ее)))

ERROR: S client not available

Ожидание - кинул 5 запросов. На сервере первый взял строку стал с ней работать. Второй взял вторую строку и тд. За 5 сек отработали все 5 запросов. Каждый вернул свою строку и выполгился в своем потоке

Мой сервист ебет другой сервер. Каждую секунду или наносекунду пихает в меня 50 запросов. Типо есть ли для меня данные? Я должен обработать каждый запрос. Если есть 30 строк в бд 30 запросам вернуть по одной строке из бд а 20 сказать - ниче нет.

Архетиктура огонь но вот так вот. Повлиять не могу

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

Да

Но решить ее селект фор апдейтом не выходит

а в нэйтив квэри ты руками ставишь лок на последнюю строчку?

или как?

Почему не сделать очередь + издатель-подписчик с long-polling?

я в твоем алгоритме не увидел это

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

а в нэйтив квэри ты руками ставишь лок на последнюю строчку?

Да там типо for u.GUID skip lock

А что за бизнес кейс

Что-то упорото звучит

FOR UPDATE column SKIP LOCKED

А что за бизнес кейс

Я бы сказал но не могу(((

Почему не сделать очередь + издатель-подписчик с long-polling?

Потому что системой пользуются тысячи людей, и она уже реализована, по ращработанным протоколам и я не могу просто взять и поменять. Ей пользуются 3 лица

В общем один сервер долбит другой и там целая цепочка. Все всех долбят

Есть контроллер. В него приходит реквест. Контроллер дергает метод сервиса в который передает поле например имя. В сервисе метод помечен @Transactional и внутри дергает метод репозитория потом деоает задержку в 5 сек. В репозитории начинаются жксперементы. 1. @Lock(LockModeType.PESSIMISTICK_WRITE) findTop1By..... В джиметре создается 5 потоков которые кидают один и тот же реквест одновременно. Результат - выполняется первый запрос. 5 секунт отрабатывает, начинает выполняться второй запрос и тд. 2 . Переписывается на netivQuery где пишется select for update skip lock. Результат в джиметре - первый поток блокирует на 5 сек базу. Остальные 4 отваливаются так как пытаются получить доступ к этой же записи. Через 5 сек первый отрабатывает успешно

слушай, а может из-за for Update, skip locked не отрабатывает как ты хочешь

и поэтому остальные ждут?

попробуй для теста в одном треде запустить с фор апдейт

а во втором без фор апдейта, но со скипом заблокированных

Не. Если просто селект фор апдейт то первый блокирует а остальные жлут. И потом отрабатывают. А если скип локед то следующий должен взять все записи кроме заблокированой.

>А если скип локед то следующий должен взять все записи кроме заблокированой. ты уверен в этом?

Тоесть локед это уже переделка так как просто фор апдейт не работает

>А если скип локед то следующий должен взять все записи кроме заблокированой. ты уверен в этом?

Да даже картинку колега скидывал с диаграммой

но при этом у тебя выборка не работает и все 4 ждут?

Если скип локед то первый блокирует первую запись из выборки. Остальные вызываю выборку которая возвращает ту же самую строку. А она заблокирована уже. И они отваливаются