powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Java [игнор отключен] [закрыт для гостей] / Spring MVC. "Тяжелый" объект в scope session.
25 сообщений из 30, страница 1 из 2
Spring MVC. "Тяжелый" объект в scope session.
    #38552807
JackARoe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Привет!
Есть некий менеджер неких ресурсов (детали не важны - коммерческий закрытый узкоспециализированный продукт, далее назовем его условно 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
Spring MVC. "Тяжелый" объект в scope session.
    #38552847
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
JackARoe,
у тебя в этом менеджере нет ни одного положительного качества.
Напрашивается простой вывод - закэшируй его полностью. Перелей всю инфу в свою структуру и пользуйся.
Т.к. даже кластер тебе мало поможет (тормозит не сервер-железо, а сам Г. объект).
...
Рейтинг: 0 / 0
Spring MVC. "Тяжелый" объект в scope session.
    #38552852
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
тут была сходня тема, когда веб сервисы медленные, а веб форму юзверям заполнять надо
...
Рейтинг: 0 / 0
Spring MVC. "Тяжелый" объект в scope session.
    #38552882
JackARoe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Petro123JackARoe,
у тебя в этом менеджере нет ни одного положительного качества.
Напрашивается простой вывод - закэшируй его полностью. Перелей всю инфу в свою структуру и пользуйся.
Т.к. даже кластер тебе мало поможет (тормозит не сервер-железо, а сам Г. объект).

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

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

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

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

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

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

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

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

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

Опять же, совершенно не обязательно использовать встроеную кластеризаию вашего сервера. Можно взять Terracottа и\или JBoss-овские инструменты и самому построить кластер, полностью контролируя репликацю. В этом случае, вам не так важно что у вас в HttpSession, если вы сами решаете какое состояние реплицировать, а какое нет.
...
Рейтинг: 0 / 0
Spring MVC. "Тяжелый" объект в scope session.
    #38552995
cdtyjv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
Spring MVC. "Тяжелый" объект в scope session.
    #38553004
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
JackARoe1. насколько плохо положить черный ящик, который имплементит Externalizable в session scope? какие могут быть проблемы, в т.ч. на кластере?

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

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


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

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

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

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


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

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

BlazkowiczЗавести свой кэш, например, через jsessionid и SessionListener, который не будет персиститься и не будет реплицироваться.
А можно подробнее? Или другими словами? Что-то не улавливаю идею.
...
Рейтинг: 0 / 0
Spring MVC. "Тяжелый" объект в scope session.
    #38553267
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
Spring MVC. "Тяжелый" объект в scope session.
    #38553322
JackARoe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Blazkowicz,
Ну т.е. resourceManagerCache в singleton?
А если сессия реплицируется на другую ноду? там ведь будет свой кэш? авторизовываться заново в манагере и сохранять его в кэш?
...
Рейтинг: 0 / 0
25 сообщений из 30, страница 1 из 2
Форумы / Java [игнор отключен] [закрыт для гостей] / Spring MVC. "Тяжелый" объект в scope session.
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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