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

Гугл не смотрели? Поиск по тексту вашей ошибки говорит о том, что, вероятно, Вы сохранили файл .java в папке Program Files (например, в C:\Program Fiels\Java\jdk1.7.0\bin), в которой Windows по умолчанию запрещает создание и модифицирование файлов

Если вам нужны именно пользователи, то основную таблицу запроса удобнее будет взять users:

select distinct us.* from users us
inner join comments com on com.user_id = us.user_id
order by com.date

Не совсем ответ на Ваш вопрос, но всё же. Называть сведения о ЗП "высокосекретными", мягко говоря, неверно. Они не секретны, а конфиденциальны, и обычно защищаются пунктами трудового договора. Мне кажется, что у вас сейчас проблема в том, что поставлена задача, оторванная от реальности. Вы пытаетесь потратить уйму времени на разработку, породив при этом кучу проблем в последующей поддержке - на фикцию. Даже при успешной реализации, подумайте, что улучшится на предприятии? Сотрудники перестанут общаться между собой (в т.ч. тихонько интересуясь кто сколько "получает")? Компания при публикации резюме перестанет указывать вилку ЗП? Я бы порекомендовал серьезно задуматься над постановкой задачи, очень похоже на стрельбу из пушки по воробьям...

Наверное, проблема в том, что Вам в первую очередь надо понять, что подразумевается под "сервером". Обычно, имеется в виду Сервер приложений (СП), но даже самые "навороченные" сервера приложений сами по себе не могут ответить вашему клиенту даже на простейший "Привет". Ответить может серверная часть вашего приложения, развернутая под управлением СП. Т.е., сначала выбираете СП, затем читаете Гугл по поводу того, как развернуть на нем простейшее приложение с вашей логикой, и только затем выбираете какой-либо из вариантов реализации RPC и разбираетесь как развернуть его в вашей серверной логике. Разные реализации RPC могут быть доступны в СП по разным портам. На мой взгляд, более распространенными и более универсальными считаются протоколы, работающие "поверх" HTTP, в свою очередь среди них, наиболее универсальны и распространены веб-сервисы.

Таким образом:
1. Просто написать клиента не получится, задача комплексная и для новичка может быть непростой.
2. Выберите СП (для Java, обычно, Tomcat или JBoss) и погуглите как развернуть веб-сервис под его управлением.

Когда заработает, будут первичные понятия о механизмах, и готовое серверное приложение. Имея это, можно будет вернуться к исходной задаче и уже более осмысленно решить, какой именно протокол наиболее подходит под Ваши нужды.

Я бы посоветовал для начала погонять все запросы без Hibernate, а напрямую в БД и посмотреть на результаты. Либо почитать доку/погуглить насчет того, как работает ваша СУБД с регистром символов. Например, Oracle обязует указывать в условии тот же регистр, что и в БД (иначе не найдёт), а MySQL позволяет об этом не задумываться. Надежнее всего перед сохранением данных в БД приводить регистры символов в некое предопределенное состояние (например все символы в верхний регистр), а впоследствии при наложении условия на выборку также приводить регистр искомой строки. Если в базе уже мусор (кто как ввел, так и сохранилось) то можно создать индексы в нужном регистре, т.е. в поле таблицы как попало, а в индексе по этому полю всё в UPPER. Либо сделать update table set field = UPPER(field). В общем сначала смотрите в СУБД, а уже потом в Hibernate...

Видимо, универсальный метод общения в гетерогенной среде - HTTP/XML: и Java и Objective C умеют с ним работать. Например, вот тут на stackoverflow есть пара слов теории. На мой взгляд, основным минусом является то, что на каждое действие надо будет разработать метод серверной части и сделать его доступным посредством HTTP. Этого недостатка нет у различных фреймворков, которые стараются упростить написание клиентов, например JSF в Java, но тут встает вопрос о кроссплатформенности - как бы не пришлось плодить отдельную разработку под каждого программного клиента.

JSP - вещь полезная при изучении, дающая базовое понимание того, как формируются "тонкие" интерфейсы на стороне сервера. Но советую в JSP сильно не углубляться, т.к. технология устаревшая - на ее замену пришел JSF. Вообще, насчет стека технологий для изучения - почитайте ответы на похожий вопрос: С чего начать изучение Java EE

Вы не показали, как создается SomeBean. Я это к тому, что контейнер делает инъекцию в бины, которые сам создает. Если вы SomeBean создали через new, то никаких инъекций в него не будет.

Также можно покопать в сторону загрузки классов, которая в свежем JBoss-е существенно переработана, в сравнении с предыдущими версиями. Попробуйте, например в jboss-deployment-structure.xml указать <ear-subdeployments-isolated>false</ear-subdeployments-isolated>. В конце-концов, объедините core.jar и app.jar в один jar (тупо средствами WinRar-а, если долго переделывать скрипты сборки) и посмотрите, будет ли инъекция. Если будет — то 99% что надо ковырять загрузку классов. Если нет, то это скорее всего ни при чем, и надо думать дальше.

Работал с 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