Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Java [игнор отключен] [закрыт для гостей] / Spring MVC. "Тяжелый" объект в scope session. / 25 сообщений из 30, страница 1 из 2
  1  все
07.02.2014, 09:27
    #38552807
JackARoe
JackARoe
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
Привет!
Есть некий менеджер неких ресурсов (детали не важны - коммерческий закрытый узкоспециализированный продукт, далее назовем его условно 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 ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 10:06
    #38552847
Petro123
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
JackARoe,
у тебя в этом менеджере нет ни одного положительного качества.
Напрашивается простой вывод - закэшируй его полностью. Перелей всю инфу в свою структуру и пользуйся.
Т.к. даже кластер тебе мало поможет (тормозит не сервер-железо, а сам Г. объект).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 10:07
    #38552852
Petro123
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
тут была сходня тема, когда веб сервисы медленные, а веб форму юзверям заполнять надо
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 10:26
    #38552882
JackARoe
JackARoe
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
Petro123JackARoe,
у тебя в этом менеджере нет ни одного положительного качества.
Напрашивается простой вывод - закэшируй его полностью. Перелей всю инфу в свою структуру и пользуйся.
Т.к. даже кластер тебе мало поможет (тормозит не сервер-железо, а сам Г. объект).

Какую инфу закэшировать? Я же не знаю, что мне заранее понадобиться. Он по ходу дела достает ресурсы из своих источников, принимая во внимание данные своей авторизации. "Ресурсы" тут название условное, их набор не статичен и даже слабопрогнозируем.

Кластер мне не для того чтобы помогать, я не думаю что там будут жуткие тормоза чтобы лечить это кластером. Это просто данность - приложение, скорей всего, будет развертываться в кластерной среде. Поэтому я и озаботился вопросами как правильно в такой среде выстроить приложение, принимая во внимание ссылку из исходного поста..
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 10:49
    #38552927
Petro123
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
JackARoe,
- абстрактно, если данные слабопрогнозируемы и неповторяемы, то и кэш не поможет.
Т.е. вы не ускорите приложение.
Упадёт ли в кластере? Не подскажу - не строил кластеров.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 11:03
    #38552944
JackARoe
JackARoe
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
ок. видимо "много букв" в исходном посте.
сократим.
1. насколько плохо положить черный ящик, который имплементит Externalizable в session scope? какие могут быть проблемы, в т.ч. на кластере?

2. Данные слабопрогнозируемы, но возможно некое переиспользование - в начале метода запросили ресурс у ResourceManager'а положили в свой локальный кэш сервиса, поработали с ним, в середине метода опять достали только уже из локального кэша, опять поработали и т.д.
Есть смысл городить такое? Для этого я так понимаю у сервисов надо будет поставить scope request?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 11:17
    #38552958
cdtyjv
cdtyjv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
JackARoe ,
Плохо класть такую вещь в сессию, когда вы сидите в кластере. По той простой причине, что вы не сможете его нормально зареплицировать между сессиями. Например:

T1: Вы создали объект на ноде N1.
T2: Запустили нод N2, объект начал туда "утекать" в состоянии S1.
T3: В это время на нод N1 пришел запрос, который изменил состояние объекта в S2.
Вопрос: какое состояние в итоге увидит N2?

Здесь принципиальная проблема заключается в том, что в кластере легко реплицировать, условно говоря, value object'ы. То есть простые значения без какой-либо логики. А вот реплицировать полновесный сервис, у которого к тому же куча зависимостей может торчать наружу - это в общем случае задача не решаемая. Скорее всего, вам надо пересмотреть дизайн.

Самое очевидное решение выглядит следующим образом. Зачем вы для каждого пользователя создаете своего менеджера? Вместо этого вам надо создать по одному менеджеру на JVM, а каждый конкретный пользователь будет просто работать с этим сервисом-синглтоном, и получать от него какие-либо value object'ы, в которых будет описано состояние текущего пользователя относительно данного сервиса . То есть сам сервис а) синглтон; б) stateless. И тогда ваша проблема уходит сама собой.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 11:18
    #38552960
Petro123
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
JackARoe,
2. У вас метод на 100 страниц? Метод сервлета обычно длится 0,1 - 0,5 сек.
По любому "нужно в граммах" - элементарный стек-трейс с временными метками.
Чтобы найти Тяжёлые места в коде, а не сам тяжёлый объект.
Абстрактно - авторизацию вынести в начало сессии.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 11:22
    #38552971
Petro123
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
cdtyjv,
у него долго не создание экземпляра, а коннект каждого пользователя.
Это не исправить.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 11:24
    #38552975
JackARoe
JackARoe
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
cdtyjv,
все замечательно, но мне, прежде чем использовать этот сервис "черный ящик", надо "в нем" авторизоваться. И данные он мне будет отдавать сообразно своим взглядам - что мне можно, а что нельзя. Т.е. для разных пользователей его поведение будет разным. Его создание и авторизация в нем процесс не быстрый. Поэтому была мысль положить его в scope session.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 11:29
    #38552980
JackARoe
JackARoe
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
Petro123JackARoe,
...
Абстрактно - авторизацию вынести в начало сессии.

ну то есть положить этот объект в сешнскоуп?
Вот коллега cdtyjv указывает на возможные проблемы.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 11:32
    #38552987
Blazkowicz
Blazkowicz
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
JackARoe,

Тут есть некоторая путаница и недосказанность. Вы много описали о том что Manager делает. Но это не важно. Для сериализации важно какое состояние хранит в себе этот Manager. Тем более если он Externalizable, надо знать как именно в нет реализована сериализация и на сколько она дорогая.
Если, например, сериализация дешевая - Manager просто сохраняет некоторый security token и сбрасывает кэши, то проблем особых быть не должно.
Если сериализация дорогая, допустим Manager при десериализации каждый раз проходит аутентификацию и авторизацию заново, то с этим надо быть аккуратным.

В чистом JEE сериализация HttpSession влияет на два момента. Остановку\перезапуск приложения. При этом сервер сохраняет состояние HttpSession, сериализуя его в локальное хранилище. И второй это репликация состояния на другие ноды кластера. Если ваша десериализация окажется дорогой, то репликация будет отнимать значительные ресурсы кластера. Собственно я это всё, вроде в той теме и расписывал.

Опять же, совершенно не обязательно использовать встроеную кластеризаию вашего сервера. Можно взять Terracottа и\или JBoss-овские инструменты и самому построить кластер, полностью контролируя репликацю. В этом случае, вам не так важно что у вас в HttpSession, если вы сами решаете какое состояние реплицировать, а какое нет.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 11:37
    #38552995
cdtyjv
cdtyjv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
JackARoecdtyjv,
все замечательно, но мне, прежде чем использовать этот сервис "черный ящик", надо "в нем" авторизоваться. И данные он мне будет отдавать сообразно своим взглядам - что мне можно, а что нельзя. Т.е. для разных пользователей его поведение будет разным. Его создание и авторизация в нем процесс не быстрый. Поэтому была мысль положить его в scope session.Не вижу никаких проблем:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
interface Service {
    boolean auth(AuthInfo info);
}

interface User {
    AuthoInfo getAuthInfo();

    boolean isAuthorized();
    void setAuthorized(boolean authorized);
}


Где-то в сервлетах:
Код: java
1.
2.
3.
4.
5.
6.
Service svc = container.getService();

User user = ses.getAttribute("user");

if (svc.authorize(user.getAuthInfo()))
    user.setAuthorized(true);


Идея очень проста - не хранить состояние пользователя внтури сервиса. Это реализуемо абсолютно всегда.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 11:41
    #38553004
Blazkowicz
Blazkowicz
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
JackARoe1. насколько плохо положить черный ящик, который имплементит Externalizable в session scope? какие могут быть проблемы, в т.ч. на кластере?

Плохо. Externalizable может расходовать ресурсы сервера и кластера недостаточно эффективно. Если вы не знаете что там и как проиходит, и если вы лично не контролируете репликацию и перезапуск сервера, то и результат не предсказуем. :)

JackARoe2. Данные слабопрогнозируемы, но возможно некое переиспользование - в начале метода запросили ресурс у ResourceManager'а положили в свой локальный кэш сервиса, поработали с ним, в середине метода опять достали только уже из локального кэша, опять поработали и т.д.
Есть смысл городить такое? Для этого я так понимаю у сервисов надо будет поставить scope request?
Что-то я не понял идеи. Надо кешировать - кешируйте. Надо реплицировать кеш на кластере - реплицируйте. Если это все действительно позволяет съэкономить ресурсы, то почему нет.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 12:03
    #38553051
JackARoe
JackARoe
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
cdtyjv,
вот здесь
Код: java
1.
svc.authorize(user.getAuthInfo())


все умрет если делать это регулярно. авторизация дорогая, а без нее никаких ресурсов этот черный ящик не вернет.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 12:07
    #38553062
JackARoe
JackARoe
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
Blazkowicz,

1. Спасибо. А есть мысли, что делать в такой ситуации?

2. Ну да пардон, коллеги. Действительно, вопрос слишком "ни о чем". надо будет еще поэкспериментировать.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 12:08
    #38553064
Petro123
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
JackARoePetro123JackARoe,
...
Абстрактно - авторизацию вынести в начало сессии.

ну то есть положить этот объект в сешнскоуп?
Вот коллега cdtyjv указывает на возможные проблемы.
он, и не только он, указали на проблемы внутрикластерные.
Но ведь туда кладут не только для кластеризации.
Вам нужно поднять скоуп и вывести из функции авторизацию.
Вот и займитесь этим в 1 очередь.
Если объект не кластеризуется, то вы просто будете им управлять (при смене ноды новая сессия).
Т.к. получите ошибку при очередном запросе неавторизованного.
IMHO
PS.
Я так понимаю, что эти магические рессурсы ведь тоже надо реплицировать на все ноды кластера.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 12:17
    #38553083
cdtyjv
cdtyjv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
JackARoecdtyjv,
вот здесь
Код: java
1.
svc.authorize(user.getAuthInfo())


все умрет если делать это регулярно. авторизация дорогая, а без нее никаких ресурсов этот черный ящик не вернет.
Елки палки, это же псевдокод, что бы показать идею, как вынести состояние юзера из сервиса. :-) Я же не говорю вам, что это надо вызывать на каждом запросе. Вытащили из сессии пользователя. Посмотрели на его статус. Еще на авторизовывался? Ок, авторизуем. Понятное дело, что этот метод вызывается один раз на пользовательскую сессию.
А в дальнейшем вы реплицируете исключительно User. Он легкий, в нем нет логики и замысловатого внутреннего состояния. Передали уже авторизованного юзер на второй сервер, и ему уже не надо второй раз авторизовываться.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 12:19
    #38553085
Blazkowicz
Blazkowicz
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
JackARoe1. Спасибо. А есть мысли, что делать в такой ситуации?

Не пользоваться черным ящиком.
Завести свой кэш, например, через jsessionid и SessionListener, который не будет персиститься и не будет реплицироваться.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 12:20
    #38553090
Petro123
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
cdtyjvПередали уже авторизованного юзер на второй сервер, и ему уже не надо второй раз авторизовываться.
имхо будет рассогласование юзера на сервере2 и менеджера на сервере2
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 12:28
    #38553106
cdtyjv
cdtyjv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
Petro123имхо будет рассогласование юзера на сервере2 и менеджера на сервере2Не будет никакого рассогласования. Юзер и сервис общаются только через value object'ы, внутри менеджера состояния нет. Поэтому работа одного и того же юзера с разными сервисами всегда даст один и тот же результат.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 12:31
    #38553116
Petro123
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
cdtyjvвнутри менеджера состояния нет.
есть - клиент прошедший авторизацию.
Без состояния, был бы ввод пароля на каждый запрос (REST)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 13:19
    #38553242
JackARoe
JackARoe
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
cdtyjv[Не будет никакого рассогласования. Юзер и сервис общаются только через value object'ы, внутри менеджера состояния нет. Поэтому работа одного и того же юзера с разными сервисами всегда даст один и тот же результат.
Еще как есть. Один юзер - один инстанс черного ящика. Тут коллега Petro123 прав - будет рассогласование. Повторюсь - штука эта продукт третьей стороны закрытая, без исходников, коммерческая, узкоспециализированная.

BlazkowiczЗавести свой кэш, например, через jsessionid и SessionListener, который не будет персиститься и не будет реплицироваться.
А можно подробнее? Или другими словами? Что-то не улавливаю идею.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 13:28
    #38553267
Blazkowicz
Blazkowicz
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
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.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.02.2014, 13:47
    #38553322
JackARoe
JackARoe
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Spring MVC. "Тяжелый" объект в scope session.
Blazkowicz,
Ну т.е. resourceManagerCache в singleton?
А если сессия реплицируется на другую ноду? там ведь будет свой кэш? авторизовываться заново в манагере и сохранять его в кэш?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Java [игнор отключен] [закрыт для гостей] / Spring MVC. "Тяжелый" объект в scope session. / 25 сообщений из 30, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 530ms
Закрыть
start [/forum/topic.php?fid=59&mobile=1&tid=2127685]:
 0ms
get settings:
 10ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 180ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 70ms
get tp. blocked users:
 2ms
others: 233ms
total:  530ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]