JTalks TS. Hibernate и шаблоны работы с сессиями

 
 
 
Сообщения:9895
На данной сессии мы обсуждали проблему связанную с Hibernate при работе с desktop-like фреймворками типа ZK. Обсудили шаблон session per request (OpenSessionInView), а также session per conversation (в нашем случае это Open Session On Desktop) и почему в проекте Poulpe мы выбрали второе.
Видео запись можно посмотреть здесь.
 
 
Сообщения:619
Вопрос скорее всего из-за не понимания того как работает ZK, но все же: предусмотрено в реализации Open Session On Desktop отваливание по какому-то таймауту?
Listener вроде бы обрабатывает событие destroying an exection ( http://www.zkoss.org/javadoc/6.0.0/zk/org/zkoss/zkplus/hibernate/HibernateSessionContextListener.html #cleanup) и чистит сессию сопоставленную с этим десктопом. ZK гарантирует срабатывание этого события даже в том случае если хомячок перегрыз витую пару которая воткнута в компьютер клиента?

P.S. Было бы любопытно узнать о решении проблемы с теоретическим OOM при загрузке большого количества юзеров несколькими очень терпеливыми админами:) Слышал мнение, что в случае загрузки большого количества данных хранить их лучше всего на клиентской стороне с грамотной инвалидацией при разработке на RIA(тот же LocalStorage в HTML5). Одно из самых устойчивых решений проблемы пейджирования.
 
 
Сообщения:9895
Да, ZK гарантирует уничтожение Desktop'a по перезагрузке страницы и по инвалидации сессии.
Да, сессия в идеале должна содержать как можно меньше объектов и в случае с RIA возможно как-то получится загружать их по сердствам WS, однако проблемы будут опять же с синхронизацией того, что видит пользователь и того, что в БД, а также в задержках, ибо у нас решение такое было принято в основном из-за уменьшения задержек, ну и исходя из того, что админов одновременно больше 2х не бывает (ну во всяком случае у нас).
 
 
Сообщения:2436
Вообще open-session in view свидетельствует о больших проблемах в архитектуре: слой представления данных недееспособен в формировании запросов на выборку, тобишь запрашивает абы чо не имея четкого представления что ему нужно, а слой выбирающий данные не имеет гибкого удобного интерфейса позволяющего выбирать всё за один запрос, без магии с ленивой загрузкой. Обычно к антипаттерну open-session in view приводит, то что доменную модель пытаются использовать в слое представления.
 
 
Сообщения:390
Taky_:

Слышал мнение, что в случае загрузки большого количества данных хранить их лучше всего на клиентской стороне с грамотной инвалидацией при разработке на RIA(тот же LocalStorage в HTML5). Одно из самых устойчивых решений проблемы пейджирования.

Ага открываем веб страничку и скачиваем на клиента пару терабайт, подумаешь пару дней сайт будет открываться, зато потом всё будет летать. Никакого отношения LocalStorage к визуализации больших объемов данных и близко не имеет.
 
 
Сообщения:619
vimba:
Taky_:

Слышал мнение, что в случае загрузки большого количества данных хранить их лучше всего на клиентской стороне с грамотной инвалидацией при разработке на RIA(тот же LocalStorage в HTML5). Одно из самых устойчивых решений проблемы пейджирования.

Ага открываем веб страничку и скачиваем на клиента пару терабайт, подумаешь пару дней сайт будет открываться, зато потом всё будет летать. Никакого отношения LocalStorage к визуализации больших объемов данных и близко не имеет.

А как вы решили бы задачу отображения пары терабайт в веб приложении? :D
 
 
Сообщения:390
Логично предположить, что подгружать частями по мере необходимости.
 
 
Сообщения:619
В таком случае повышается нагрузка на БД и ухудшается возможность масштабирования относительно пользователей(не говорю что это смертельно), в случае админки все впорядке. Если запрос тяжелый, то большое количество может убить БД(Обаботка нескольких тб в нашем случае :) ).
Было бы неплохо сказать о возможной реализации, может я что-то упускаю:
1. Держать connection к базе на курсор с данными - конечно удерживается весьма ценный ресурс и нулевое масштабирование относительно пользователей. Но выполняем только один запрос.
2. Скипать нужное количество данных(page_size*page_count). Надо понимать что ResultSet должен быть Forward_only, т.к. скипанные данные с точки зрения памяти дорого хранить.

Просто кажется логичным, что если пользователь действительно хочет получить тб информации, то пусть сам за это расплачивается. Может утром пока пьет кофе загрузит инфу, а потом целый день с ней работает.
Так же решение зависит от целевой аудитории(Web, EE), необходимости дейтсивтельно одновременно работать с тб этих данных, ширины и доступности канала у пользователя.

P.S. Я не говорю что LocalStorage только для обработки большого количества данных и клиентского кеша.
 
Модераторы:masyan
Сейчас эту тему просматривают:Нет