Владимир Смирнов

Работал с JSF пару лет на паре проектов, впечатления не из лучших. JSF красив только в примерах, типа написал десяток строчек — получил полнофункциональный интерфейс. Когда пишешь реальные приложения, вот так красиво можно разве что прототип накидать, когда же дело доходит до специфических рюшечек, да и просто сложной функциональности, все становится плохо. Код превращается в мешанину, в которой все спутано: логика размазана между страницами и серверными компонентами, на клиенте часть логики, на сервере — работа с интерфейсом. Сами страницы — гремучая смесь html/el/javascript и еще черт знает чего. Всегда надо помнить о цикле обработки JSF-страницы, чтобы, например, не читать из базы 7 раз одни и те же данные в момент обновления пары визуальных элементов на странице. Также надо держать в голове некие магические правила, при которых все работает, и не дай Бог применить неправильную комбинацию акшонов/онкликов/онкомплитов при которой все просто перестает работать, причем каких-либо возможностей нормального дебага не существует. Да, когда уже наработаны готовые рабочие решения, типа «если надо при закрытии диалога кроме выполнения акшона, еще обновить вон тот элемент, и сообщить тому бину что-то, то делается это ТАК», то основная часть работы делается без непонятных глюков. Но даже при этом, у меня лично, рисование каждой новой JSF-странички вызывает аллергию.

Насчет связки JavaScript-фреймоврков с Java ничего не скажу, не пробовал, но подозреваю схожую с JSF историю — сначала что-то легко и красиво заработает, а потом может начать вылазить такой ужас, что JSF покажется цветочками. Не хочу этим сказать, JavaScript-фреймоврки — это плохо, а только лишь что если будете пробовать, проверяйте что-то более сложное, чем демо-странички, прежде чем применять в серьезном проекте.

Насколько мне известно, Java в вебе в большинстве случаев применяется в корпоративных приложениях, имеющих ограниченное количество постоянных пользователей. Для таких случаев очень хорошо подходит GWT — писать на нем очень удобно, т.к. всё пишется на Java. Сгенерированный клиентский JavaScript весит обычно немало, но, загружается один раз, и лежит закешированный в браузере до следующего обновления вашего ПО. А все это время между клиентом и сервером ходят только чистые данные, и никаких html-оберток над ними. За счет такой экономии, за пару часов работы первоначальная загрузка большого JavaScript-а полностью компенсируется. GWT не очень подходит для обычных сайтов в Интернете, т.к. там пользователи обычно непостоянные (открыл страничку, посмотрел, ушел и не вернулся), и каждому загружать большой JavaScript затратно. В GWT есть готовый набор основных компонентов. Также есть фреймворки над GWT, предоставляющие более комплексные компоненты, но с ними вы опять вернетесь к истории с JSF — отлично работает и быстро разрабатывается только пока просто, потом начинается ступор, раскопки и научный тык.

Мне кажется, что чтобы не зависеть от контейнера, есть два основных варианта:

1. Сделать всё самому. Например в бизнес-логику веб-сервиса добавить поля, которые нужны для авторизации (пользователь/пароль, например). Тупой и очень простой метод. Пожалуй, единственный его плюс — 100% контроль над процессом в вашей бизнес-логике, да и то, если этот контроль вам действительно нужен.
2. Использовать какой-либо распространенный стандарт, реализуемый всеми известными контейнерами. Т.е., независимость от контейнера при таком подходе подразумевает, что если стандарт реализован везде, то можно не беспокоится о том, что при смене контейнера будут сюрпризы. Например, WS-Security — распространенный, стабильный стандарт.

Кстати, смешение двух подходов тоже может иметь место. Я, например, использовал стандарт WS-Security, но в виду того, что мне нужны были дополнительные обработки, я отказался от реализации контейнера и написал свой обработчик.

Вообще, вариантов может быть немало, все зависит от имеющегося времени и желания искать и разбираться.

Видимо, всё-таки стоит пересматривать архитектуру. Примените Hibernate. Это решит и текущую проблему — Hibernate сам сгенерирует Statement и правильно заполнит поля, а в качестве бонуса сделает прозрачно за вас работу «планировался executeBatch». В начале вот этой моей длинной статьи есть пару абзацев о том, как Hibernate сам все оптимизировал при пакетной загрузке, без каких-либо прямых на то указаний. Ситуация практически один-в-один с Вашей — загрузка данных из текстового файла в БД, также с кешированием Statement-ов. Hibernate сделал все на порядок быстрее.

Непонятно, откуда удалить?

Получить значение JSESSIONID можно так:
HttpSessionEvent.getSession().getId()

Куки — это клиентский объект, соответственно существует только при обмене данными с клиентом. Поэтому, узнать куки можно из запроса, переданного от клиента (браузера), а изменить их можно в ответе клиенту. Уничтожение сессии, и соответственно событие sessionDestroyed, во многих случаях происходит без какого-либо участия клиента, например веб-сервер «убивает» сессию по таймауту, поэтому доступ к кукам отсутствует.

Способы хранения и чтения больших объемов данных

Это именно то, ради чего и разрабатываются СУБД, и именно их и следует использовать.

Единственным приемлемым на данный момент способом хранения и работы с данными выбрал для себя XML-файлы

Непонятно, причем тут вообще XML. Стандарт разрабатывался для унификации форматов при обмене информацией, с уклоном в человекочитаемость, в связи с чем избыточен, ресурсоемок и абсолютно не приспособлен для оптимального хранения данных. Даже если решили велосипед изобретать, то XML, пожалуй, худший из всех возможных вариантов. Тогда уж сливайте все в файл с разделителями и пишите собственные механизмы сохранения и выборки. Работать будет быстрее, чем XML, и ресурсов потребует во много раз меньше. При этом, что XML, что файлы с разделителями, что угодно — если вы не используете СУБД для "хранения и чтения больших объемов данных", то с 90% вероятностью можно предположить, что вы делаете что-то не так (если только вы не Гугл, конечно).

Да и сервер нагружать такими процедурами нельзя, так как работают с ним порядка 150 устройств с этим приложением. Представьте, сколько ему придется в сутки делать таких пачек инсерт-запросов, если для каждого их по 10-30 тысяч и по 3-5 раз в день

Большинство современных СУБД, будучи установлены на средний современный сервер, с легкостью проглотят пару миллионов инсертов в сутки. Да что там в сутки, буквально позавчера у меня Oracle за час отработал 15 млн инсертов в таблицу с тремя десятками полей, причем в тестовом окружении.

на планшете…… по 10-30 тысяч и по 3-5 раз в день

Если это планшет, значит данные генерирует пользователь, а не какой-нибудь автоматизированный датчик. Тут вопрос, что же там такого может нагенерить пользователь? Может вам следует пересмотреть архитектуру приложения? Или нормализовать сохраняемые данные? Это я так, на всякий случай спрашиваю, а то мало ли… У вас ведь грамотный архитектор на проекте есть, да?

1. Странно, а почему автор не интересуется проблемами с XA у его реализации JMS? Вы ведь хотите объединить в одну транзакцию двух провайдеров: СУБД и JMS. Причем исторически СУБД по части транзакций являются более продвинутыми, это одна из их основных функций, в то время как у сервисов доставки сообщений основной уклон немного в другую сторону. Мне кажется, что возможными проблемами с XA у вашего JMS-провайдера следовало бы озаботиться в первую очередь.

2. Из личного опыта: как-то сталкивался с похожей ситуацией, появилось желание объединить в одну XA-транзакцию JMS (IBM WebSphere MQ) и СУБД (Oracle). Не получилось, лезли какие-то глюки. Это было очень давно, возможно я не разобрался до конца, возможно технологии XA тогда были еще сырые, не важно. Я тогда пошел другим путем. В проекте использовался ORM (Hibernate), соответственно все обращения к СУБД шли через эту прослойку. Так вот, я подумал, что раз и так все делается через Hibernate, то почему бы не посмотреть что там есть по части объединения различных ресурсов в одну транзакцию. И оказалось, что таки есть. У org.hibernate.Transaction есть метод registerSynchronization, который принимает объект, реализующий методы beforeCompletion и afterCompletion. В методе beforeCompletion я и реализовал завершение транзакции JMS. Конечно, такой подход можно считать менее надежным, чем XA-технологии, но абсолютно надежных транзакций не существует. Добавлю лишь, что система высоконагруженная (порядка миллиона транзакций в сутки, из них треть с использованием вышеописанной связки СУБД и JMS, и за 6 лет промышленной эксплуатации вопросов/проблем связанных с именно такой реализацией не было. Так что, на мой взгляд, достойный вариант, не имеющий глюков (по крайней мере в одной системе за 6 лет).

10 лет разрабатываю JEE-приложения, и всегда конфигурация была слабее. В данный момент на работе уже 3 года веду разработку на ноутбуке, точно не помню какой процессор (пишу сейчас из дома), перед линейкой i3/5/7 выпускался, кажется Core 2. Памяти 3 Гб. Запускаю среду Idea, пару интсансов сервера JBoss, веб-сервер httpd, и даю на все это нагрузку в SOAPUi — десятки тысяч запросов посредством веб-сервисов, и все работает вполне себе неплохо. Пока идет нагрузочный тест без особых проблем работаю в Idea.

Дома i3 3000 ГГц, 4 ГБ памяти. Установлен MySQL, в базе сейчас порядка 300 тысяч записей (незапакованный дамп весит полгига). Сервера приложений правда нет. Запускаю из Idea свой софт, который достаточно интенсивно работает с базой, сам дальше программирую и запускаю другие разработки — вообще никаких намеков на тормоза.

Идите путем исключений: останавливайте поочередно все запущенные компоненты (сервер, среда разработки и т.д.), пока не заметите, что компьютер «задышал полной грудью», тогда поймете где проблема. В конце-концов, диспетчер задач ясно показывает кто ест память или процессор. Существует также немалая вероятность того, что JEE тут вообще ни при чем, а проблема в неисправном железе или покалеченной ОСи.

В какой момент времени и при каких условиях «срабатывает» данная аннотация?

Для того, чтобы аннотация сработала, требуется наличие настроенного источника данных, развертываемого сервером JBoss до старта вашего приложения (что достигается указанием зависимостей в вашем развертываемом модуле), а также подключение вашей бизнес-логики в качестве модуля в EAR, для чего в application.xml указать

<module>
        <java>ваша-логика.jar</java>
</module>

И, да, обычно указывается аннотация @PersistenceContext либо @PersistenceUnit

Как вариант: попробуйте взглянуть как-то по-другому на свое дерево. Понять, что на самом деле хочет сделать пользователь. Я это к тому, что уже сказали о том, что вряд-ли такое огромное дерево кто-то будет смотреть. Может быть, там вообще не нужно именно дерево?

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

А может, вашему пользователю вообще не нужно последовательно идти по всему древу, может ему удобнее ввести какое-то условие фильтрации и сделать сквозную выборку, не зависящую от уровня? В общем, IMHO — с деревом проблем нет, а вот насчет правильности постановки реализуемой Вами задачи есть сомнения.