|
|
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
Привет! Есть некий менеджер неких ресурсов (детали не важны - коммерческий закрытый узкоспециализированный продукт, далее назовем его условно CustomResourceManager). Он выдает и освобождает по требованию некоторые ресурсы - customResourceManager.get(resourceName), customResourceManager.release(resource). get и release происходят достаточно быстро. но перед тем как пользоваться этим менеджером, его нужно создать и выполнить авторизацию в нем (customResourceManager.login(login, password)). И вот эти действия - создание и авторизация достаточно дорогие, уходит заметное время. Далее вся его работа по выдаче ресурсов происходит на основе авторизационных данных. Сразу скажу, что этот CustomResourceManager не имеет отношения ни к security, ни к работе с субд в нашем приложении. Есть два вопроса. Первый вопрос: Как реализовать нормально? Предполагалось: 1. При логине в приложении создаем customResourceManager, авторизуемся в нем и кладем его в session scoped with aop:scoped-proxy. 2. Далее контроллеры (singleton) вызывают сервисы (singleton), в которые заинжектены resourceManager (session scoped with aop:scoped-proxy). Вроде бы все(???) нормально? Но прочитал вот это: http://www.sql.ru/forum/1002871/session-scope-dlya-controller и стали терзать смутные сомнения. Работать приложение вполне возможно будет в кластере. Класс этого resourceManagera имплементит java.io.Externalizable. так что проблем с сериализацией быть не должно? Какие тут еще подводные камни могут быть? Второй вопрос: Несмотря на то что выдача ресурсов этим менеджером быстрая, она все таки медленее чем чтение локальных данных. есть идея кэшировать эти ресурсы в сервисах (или не в самих сервисах, а уровнем ниже придумать какой-то ResourceDAO), тогда сервисам (или DAO) выставить scope request. Никаких состояний после обработки хранить не надо, а вот в процессе обработки кэширование помогло бы. Есть смысл в таком кэше и request scope'е для сервисов и DAO ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 09:27 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
JackARoe, у тебя в этом менеджере нет ни одного положительного качества. Напрашивается простой вывод - закэшируй его полностью. Перелей всю инфу в свою структуру и пользуйся. Т.к. даже кластер тебе мало поможет (тормозит не сервер-железо, а сам Г. объект). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 10:06 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
тут была сходня тема, когда веб сервисы медленные, а веб форму юзверям заполнять надо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 10:07 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
Petro123JackARoe, у тебя в этом менеджере нет ни одного положительного качества. Напрашивается простой вывод - закэшируй его полностью. Перелей всю инфу в свою структуру и пользуйся. Т.к. даже кластер тебе мало поможет (тормозит не сервер-железо, а сам Г. объект). Какую инфу закэшировать? Я же не знаю, что мне заранее понадобиться. Он по ходу дела достает ресурсы из своих источников, принимая во внимание данные своей авторизации. "Ресурсы" тут название условное, их набор не статичен и даже слабопрогнозируем. Кластер мне не для того чтобы помогать, я не думаю что там будут жуткие тормоза чтобы лечить это кластером. Это просто данность - приложение, скорей всего, будет развертываться в кластерной среде. Поэтому я и озаботился вопросами как правильно в такой среде выстроить приложение, принимая во внимание ссылку из исходного поста.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 10:26 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
JackARoe, - абстрактно, если данные слабопрогнозируемы и неповторяемы, то и кэш не поможет. Т.е. вы не ускорите приложение. Упадёт ли в кластере? Не подскажу - не строил кластеров. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 10:49 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
ок. видимо "много букв" в исходном посте. сократим. 1. насколько плохо положить черный ящик, который имплементит Externalizable в session scope? какие могут быть проблемы, в т.ч. на кластере? 2. Данные слабопрогнозируемы, но возможно некое переиспользование - в начале метода запросили ресурс у ResourceManager'а положили в свой локальный кэш сервиса, поработали с ним, в середине метода опять достали только уже из локального кэша, опять поработали и т.д. Есть смысл городить такое? Для этого я так понимаю у сервисов надо будет поставить scope request? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 11:03 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
JackARoe , Плохо класть такую вещь в сессию, когда вы сидите в кластере. По той простой причине, что вы не сможете его нормально зареплицировать между сессиями. Например: T1: Вы создали объект на ноде N1. T2: Запустили нод N2, объект начал туда "утекать" в состоянии S1. T3: В это время на нод N1 пришел запрос, который изменил состояние объекта в S2. Вопрос: какое состояние в итоге увидит N2? Здесь принципиальная проблема заключается в том, что в кластере легко реплицировать, условно говоря, value object'ы. То есть простые значения без какой-либо логики. А вот реплицировать полновесный сервис, у которого к тому же куча зависимостей может торчать наружу - это в общем случае задача не решаемая. Скорее всего, вам надо пересмотреть дизайн. Самое очевидное решение выглядит следующим образом. Зачем вы для каждого пользователя создаете своего менеджера? Вместо этого вам надо создать по одному менеджеру на JVM, а каждый конкретный пользователь будет просто работать с этим сервисом-синглтоном, и получать от него какие-либо value object'ы, в которых будет описано состояние текущего пользователя относительно данного сервиса . То есть сам сервис а) синглтон; б) stateless. И тогда ваша проблема уходит сама собой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 11:17 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
JackARoe, 2. У вас метод на 100 страниц? Метод сервлета обычно длится 0,1 - 0,5 сек. По любому "нужно в граммах" - элементарный стек-трейс с временными метками. Чтобы найти Тяжёлые места в коде, а не сам тяжёлый объект. Абстрактно - авторизацию вынести в начало сессии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 11:18 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
cdtyjv, у него долго не создание экземпляра, а коннект каждого пользователя. Это не исправить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 11:22 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
cdtyjv, все замечательно, но мне, прежде чем использовать этот сервис "черный ящик", надо "в нем" авторизоваться. И данные он мне будет отдавать сообразно своим взглядам - что мне можно, а что нельзя. Т.е. для разных пользователей его поведение будет разным. Его создание и авторизация в нем процесс не быстрый. Поэтому была мысль положить его в scope session. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 11:24 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
Petro123JackARoe, ... Абстрактно - авторизацию вынести в начало сессии. ну то есть положить этот объект в сешнскоуп? Вот коллега cdtyjv указывает на возможные проблемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 11:29 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
JackARoe, Тут есть некоторая путаница и недосказанность. Вы много описали о том что Manager делает. Но это не важно. Для сериализации важно какое состояние хранит в себе этот Manager. Тем более если он Externalizable, надо знать как именно в нет реализована сериализация и на сколько она дорогая. Если, например, сериализация дешевая - Manager просто сохраняет некоторый security token и сбрасывает кэши, то проблем особых быть не должно. Если сериализация дорогая, допустим Manager при десериализации каждый раз проходит аутентификацию и авторизацию заново, то с этим надо быть аккуратным. В чистом JEE сериализация HttpSession влияет на два момента. Остановку\перезапуск приложения. При этом сервер сохраняет состояние HttpSession, сериализуя его в локальное хранилище. И второй это репликация состояния на другие ноды кластера. Если ваша десериализация окажется дорогой, то репликация будет отнимать значительные ресурсы кластера. Собственно я это всё, вроде в той теме и расписывал. Опять же, совершенно не обязательно использовать встроеную кластеризаию вашего сервера. Можно взять Terracottа и\или JBoss-овские инструменты и самому построить кластер, полностью контролируя репликацю. В этом случае, вам не так важно что у вас в HttpSession, если вы сами решаете какое состояние реплицировать, а какое нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 11:32 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
JackARoecdtyjv, все замечательно, но мне, прежде чем использовать этот сервис "черный ящик", надо "в нем" авторизоваться. И данные он мне будет отдавать сообразно своим взглядам - что мне можно, а что нельзя. Т.е. для разных пользователей его поведение будет разным. Его создание и авторизация в нем процесс не быстрый. Поэтому была мысль положить его в scope session.Не вижу никаких проблем: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Где-то в сервлетах: Код: java 1. 2. 3. 4. 5. 6. Идея очень проста - не хранить состояние пользователя внтури сервиса. Это реализуемо абсолютно всегда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 11:37 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
JackARoe1. насколько плохо положить черный ящик, который имплементит Externalizable в session scope? какие могут быть проблемы, в т.ч. на кластере? Плохо. Externalizable может расходовать ресурсы сервера и кластера недостаточно эффективно. Если вы не знаете что там и как проиходит, и если вы лично не контролируете репликацию и перезапуск сервера, то и результат не предсказуем. :) JackARoe2. Данные слабопрогнозируемы, но возможно некое переиспользование - в начале метода запросили ресурс у ResourceManager'а положили в свой локальный кэш сервиса, поработали с ним, в середине метода опять достали только уже из локального кэша, опять поработали и т.д. Есть смысл городить такое? Для этого я так понимаю у сервисов надо будет поставить scope request? Что-то я не понял идеи. Надо кешировать - кешируйте. Надо реплицировать кеш на кластере - реплицируйте. Если это все действительно позволяет съэкономить ресурсы, то почему нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 11:41 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
cdtyjv, вот здесь Код: java 1. все умрет если делать это регулярно. авторизация дорогая, а без нее никаких ресурсов этот черный ящик не вернет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 12:03 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, 1. Спасибо. А есть мысли, что делать в такой ситуации? 2. Ну да пардон, коллеги. Действительно, вопрос слишком "ни о чем". надо будет еще поэкспериментировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 12:07 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
JackARoePetro123JackARoe, ... Абстрактно - авторизацию вынести в начало сессии. ну то есть положить этот объект в сешнскоуп? Вот коллега cdtyjv указывает на возможные проблемы. он, и не только он, указали на проблемы внутрикластерные. Но ведь туда кладут не только для кластеризации. Вам нужно поднять скоуп и вывести из функции авторизацию. Вот и займитесь этим в 1 очередь. Если объект не кластеризуется, то вы просто будете им управлять (при смене ноды новая сессия). Т.к. получите ошибку при очередном запросе неавторизованного. IMHO PS. Я так понимаю, что эти магические рессурсы ведь тоже надо реплицировать на все ноды кластера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 12:08 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
JackARoecdtyjv, вот здесь Код: java 1. все умрет если делать это регулярно. авторизация дорогая, а без нее никаких ресурсов этот черный ящик не вернет. Елки палки, это же псевдокод, что бы показать идею, как вынести состояние юзера из сервиса. :-) Я же не говорю вам, что это надо вызывать на каждом запросе. Вытащили из сессии пользователя. Посмотрели на его статус. Еще на авторизовывался? Ок, авторизуем. Понятное дело, что этот метод вызывается один раз на пользовательскую сессию. А в дальнейшем вы реплицируете исключительно User. Он легкий, в нем нет логики и замысловатого внутреннего состояния. Передали уже авторизованного юзер на второй сервер, и ему уже не надо второй раз авторизовываться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 12:17 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
JackARoe1. Спасибо. А есть мысли, что делать в такой ситуации? Не пользоваться черным ящиком. Завести свой кэш, например, через jsessionid и SessionListener, который не будет персиститься и не будет реплицироваться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 12:19 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
cdtyjvПередали уже авторизованного юзер на второй сервер, и ему уже не надо второй раз авторизовываться. имхо будет рассогласование юзера на сервере2 и менеджера на сервере2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 12:20 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
Petro123имхо будет рассогласование юзера на сервере2 и менеджера на сервере2Не будет никакого рассогласования. Юзер и сервис общаются только через value object'ы, внутри менеджера состояния нет. Поэтому работа одного и того же юзера с разными сервисами всегда даст один и тот же результат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 12:28 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
cdtyjvвнутри менеджера состояния нет. есть - клиент прошедший авторизацию. Без состояния, был бы ввод пароля на каждый запрос (REST) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 12:31 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
cdtyjv[Не будет никакого рассогласования. Юзер и сервис общаются только через value object'ы, внутри менеджера состояния нет. Поэтому работа одного и того же юзера с разными сервисами всегда даст один и тот же результат. Еще как есть. Один юзер - один инстанс черного ящика. Тут коллега Petro123 прав - будет рассогласование. Повторюсь - штука эта продукт третьей стороны закрытая, без исходников, коммерческая, узкоспециализированная. BlazkowiczЗавести свой кэш, например, через jsessionid и SessionListener, который не будет персиститься и не будет реплицироваться. А можно подробнее? Или другими словами? Что-то не улавливаю идею. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 13:19 |
|
||
|
Spring MVC. "Тяжелый" объект в scope session.
|
|||
|---|---|---|---|
|
#18+
JackARoeА можно подробнее? Или другими словами? Что-то не улавливаю идею. С сервлетами знакомы? Когда вам надо получить экземпляр Manager-а, вместо session.getAttribute("ResourceManager") - (это спринг делает за вас для Session Scope Bean) делайте resourceManagerCache.get(session.getId()) http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpSessionListener.html - поможет вам удалять экземпляры из кэша. Создание, можно было бы тоже сделать в HttpSessionListener. Но лучше в самом resourceManagerCache. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2014, 13:28 |
|
||
|
|

start [/forum/topic.php?fid=59&fpage=187&tid=2127685]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
34ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 226ms |
| total: | 350ms |

| 0 / 0 |
