Тестирую проделанную работу. Эта ошибка была изначально, но теперь хочу избавиться от нее окончательно. Тестирую на локальной машине.

Запускаю, захожу. Проделав с десяток однотипных действий (поочередно изменяю язык вывода контента, нажимая на кнопки, - все работает, стринги подгружает из базы, одним словом, все корректно и работает именно так, как задумано), выдает ошибку:

<<
type Exception report

message

description The server encountered an internal error () that prevented it from fulfilling this request.

exception

java.lang.NullPointerException
com.simple.db.impl.SimpleProjectQuery.makeQuery(SimpleProjectQuery.java:46)
com.simple.db.impl.SimpleProjectQuery.getLabel(SimpleProjectQuery.java:88)
com.simple.servlets.MainWebServlet.processChangeStrings(MainWebServlet.java:193)
com.simple.servlets.MainWebServlet.process(MainWebServlet.java:68)
com.simple.servlets.MainWebServlet.doPost(MainWebServlet.java:33)
javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)


note The full stack trace of the root cause is available in the Apache Tomcat/5.5.17 logs.
>>

Если перезагрузить Tomcat, то все снова работает отлично ... но недолго.
Покопался в инете, вроде это как-то связано с настройками Tomcat.
В моем случае исключение вызвано при работе с базой (именно при закрытии брокера).
Практически уверен, что при аплоаде на хост ошибки не будет, но очень бы хотелось, чтобы ее не было и у меня на локальной машине.

Кто сталкивался, хелп.

Да вроде нет ...

Я видел где-то объяснение, что Tomcat может переназначать порт, и когда после этого идет снова обращение по старому, он дает сбой.

На всякий случай покажу, где выдает сбой:

<<
private Collection makeQuery(Query query)
{
Collection list = null;
PersistenceBroker broker = null;
try {
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
list = broker.getCollectionByQuery(query);
} catch (Exception exc) {
} finally {
broker.close();
}
return list;
}
>>

Сбой дает в строке briker.close().

Это вопрос или просто желание погрубить? - Нет дельного совета, не надо обливать грязью.

Знаю, что ошибка типичная, а не локальная и код тут ни при чем: сто раз подряд выполняется функция, а на 101-ый дает сбой, причем, меняется только стринговая переменная, даже отсутствие которой не инициирует исключение.
И знаю, что дело тут либо в настройках Tomcat, либо во взаимодействии сервера с PostgreSQL.

:) так оно и есть

Открытие пула происходит при первом обращении к классу PersistanceBrokerFactory (это класс библиотеки OJB). А PersistenceBrokerFactory.defaultPersistenceBroker() только указывает на него (точнее, юзер не касается таких понятий как соединение или пул - все это за него делает OJB, предоставляя брокер, посредством которого осуществляется доступ к таблицам или выполнение запросов БД). Поэтому уж про что, про что, а про непосредственное соединение тут речь идти не может.

В общем-то, проблему решил.
Как и говорил, проблема в настройках. Только не Томкета, а самого OJB. Пришлось покапать немного доки и вернуться на свою машину в файлик конфигурации OJB - OJB.properties.

(Возможно, не все мои выражения достаточно корректны, но суть от этого не меняется)
Дело в том, что самим OJB открывается пул (как вы понимаете - один единственный), для которого сам OJB лимитирует количество активных брокеров, количество idle брокеров, а также время реакции на запросы брокеров (к примеру - максимальное время отзыва базы, после которого вызывается исключение). Кроме этого, есть такой важный параметр - "ConnectionFactory / Default ConnectionPool" - способ создание пула (соединения) и брокеров; к примеру, можно, чтобы для каждой транзакции открывался новый пул, инициировался брокер, выполнялся запрос и пул закрывался.

Все эти параметры по умолчанию стоят для удаленного сервера, где время от запроса юзера до его получения несравненно больше, чем на виртуальном сервере, организованном на отдельно взятом компьютере. Поэтому при выполнении запросов на локальном Томкете при частом поступлении запросов (как это было у меня) наступал момент, когда мой класс не мог получить "свободного" брокера и вызывалось исключение. Я поменял тип класса в настройках ОДжиБи и исключения больше не вызываются, сколько бы я не совершал однотипных действий. Правда, немного стало заметно, что запросы стали производиться немного дольше (исключительно субъективное мнение).

Кроме этого, грешу на свой компьютер, который для веб-разработок на eclipse под Java, мягко говоря, слабоват, не успевая принудительно закрывать открытые брокеры.

Также хочу сделать замечание по поводу кода.
Нельзя не согласиться, что исправленный вами код выглядит "элегантнее", но дело в том, что почему-то я больше доверяю такой дворовой компании как Apache, перу которой принадлежит и OJB. А мой код, мягко говоря, содран с их сайта: apache -> db -> ojb -> docs -> tutorials.

Большое спасибо, вопрос снимается.

Да, и ответ на последний пост: OJB действительно пользуется служебными таблицами, которые надо пальчиками (*.sql имеется) занести в свою БД, которых целых 9 (!). Кстати, этот момент также можно считать недостатком, правда за удобства всегда надо платить.