Petro123vimba,
ВАС тянет на офттоп.
- сколько байт тратит сервер на коннект?
В моей конфигурации PostgreSQL я выделяю 8 мегабайт на коннект.

IDVsbruckvimbaЧито? Вы предлагаете одну одновременно выполняющаяся транзакция или один одновременный запрос к базе на выборку?
Я бы не то что ломался, а просто пристрелил бы вас на месте или выслал бы за вами киллера в Россию, тут достаточно как вам выше уже указали ввести пул соединений, чтобы коннекшн не открывался при каждом запросе, а брался готовый из пула, ну и когда база слишком уж удалена от сервера приложений это тоже не гуд, нужно с этим что-то в дальнейшем делать, например вводить WEB сервисы, потому как JDBC некошерно себя ведёт когда СУБД далеко от сервера приложений.
Читай внимательнее. Речь идет о переделке архитектуры под пул запросов.

О какой такой переделке архитектуры идёт речь? Я В ШОКЕ! Согласно DRY у вас должен быть только один метод на все приложение открывающий коннекшн, переписать один метод это пять-десять минут не более, Если кто-то до Вас набыдлокодил и загнал вас в ситуацию когда код взятия коннекшена размазан по всему приложению, то я конечно вам сочуствую но у вас нет другого выхода, кроме как отрефакторить негативно сложившуюся ситуацию.

Есть еще вариант по пределыванию всевозможных костылей: Например косяки архитектуры связанные с отсутсвием пула на уровне приложения в PostgreSQL можно легко подправить через PgBouncer уверен что для других баз существуют аналогичные средства борьбы с нерадивыми разработчиками. Конечно производительность будет слегка проигрывать по сравнению с решением использования пула непосредственно в приложении, но если деваться некуда то и такие костыли дадут весомый прирост в производительности по сравнению с открытием нового соединения под каждый запрос.

IDVsbruckP.S. Россия? - Упаси боже!
Зря вы так, в рашке наверно даже школьник из восьмого бэ не станет открывать каждый раз коннекшн а воспользуется пулом.

Petro123vimbaсредства борьбы с нерадивыми разработчиками.
а ты сам разработчик? HelloWorld напишешь?


Такой хеловорлд на фреймворке ZK в зачёт пойдёт?

Непонятно с чем ты споришь и в чем смысл твоих нападок? Пул в приложении не делают только ламеры(в веб приложении естественно, десктоп отдельная история). Если ты не согласен то тебе прямая дорога воевать с ORACLE, Microsoft, IBM, Redhat, иди и обосновывай им какие они идиоты, потому что мне тебе сказать нечего.

Petro123 vimba ,
Почему бы твой оффтоп не перенести?
Почему оффтоп, я по крайней мере намекнул автору, что есть решения и без переписывания кода, такое как всторить балансировщик между реальным сервером БД и сервером приложений, при этом балансировщик будет вести себя как обычная БД и не потребует переписывания кода, помоему такого решения в этой теме еще не было поэтому оффтопом его не считаю.

Petro123 vimba ,
http://docs.oracle.com/cd/E11882_01/server.112/e10713/dist_pro.htm#CNCPT1896
http://docs.oracle.com/cd/E11882_01/server.112/e10595/manproc002.htm#BABFCIEE
Почему бы твой оффтоп не перенести?
Что ты хочешь сказать этими ссылками? Изъятие коннекшена из спсика находящемся на той же машине быстрее чет отправка запроса на подключения в балансер, при том что нужно еще учесть факт, что в случае балансера все данные будут проходить через третье звено(балансер), которое в случае пула встренного в приложение не нужно, так что я ничего не понимаю что ты хотел сказать этими ссылками, ведь перфоманс полюбому просядет из-за наличия посредника.

Petro123vimba,
разве я спорю? Я против выражений беспредельщика: - "говнокод, ламеры" и т.д. Не зная проекта автора.
Сейчас ты разделил весь IT на веб и не веб. Завтра ты увидишь другие оттенки.
ЗЫ
Hello не пойдёт, пула не вижу.
Ты его тоже не знаешь поэтому не нужно надрывать свою пятую точку, и наезжать на того кто к тебе ближе географически, это раз. А второе, тот кто в веб не использует пул при соединении с базой это ламер, и я любому объясню почему это так. Хотя конечно средства современных СУБД и позволяют завуалировать последствия его ламерства но не на 100%.

Petro123Hello не пойдёт, пула не вижу.
Хорошо тоды так:




А так в зачет пойдёт? Пул я заюзал, вроде всё необходимое сделал, или ещё будут какие нибудь замечания?

Petro123vimbaЧто ты хочешь сказать этими ссылками?
то что твои слова тут не имею никакого отношения к теме топика и проблеме автора.
Или коротко - OFFTOP. Есть тема для этого - там литература и образы киллера не нужны.
Мне флейм про коня в вакууме неинтересен.
Я прочёл про твой балансировщик.
Удачи !
Всё ясно у тебя явно батхерт. Как раз таки вся проблемя автора в излишних открытиях соединений там где это не нужно, правильный путь рещения это переписать код чтобы такого беспредела не происходило, менее затратный но проигрывающий в производительности это встроить посередине балансировщик. Что в предидущем предложении:
1 Тебе кажется неконкретным?
2 Не решающим проблему автора? И каково твоё великолепное решение, если ты не согласен c чем-то?

Petro123vimba, :)
когда будет флейм про ОРМ, ты скажешь что: "без ОРМ пишут ламеры". Нужен ОРМ.
Нет конкретно в этом случае, дело слишком запутанное чтобы раздавать ярлыки направо и налево, я сам в каждом приложении миксую подход с ORM и без него в зависимости от конкретной ситуации, но вот тот кто начинает что-то писать не прочитав спеку и дело заканчивается фейлом, хотя в спеке всё черным по белому расписанно под определение ламера вполне попадает.

Petro123vimba1 Тебе кажется неконкретным?
2 Не решающим проблему автора? И каково твоё великолепное решение, если ты не согласен c чем-то?
перечитай sphinx_mv . Я не виноват. но он мне больше понравился.
Петя ты вообще в JDBC что нибудь понимаешь? Вникни внимательно в то что предлагает сфинкс:
sphinx_mvЕсли меня не подводит склероз, медитации на тему ODBC Connection Pool (как минимум) вполне может справиться с вашей проблемой по использованию пула соединений не особо ковыряясь в приложении.

Чел предлагает использовать прослойку JDBC/ODBC, которая как снизит перфоманс в связи с тем что возможности родного драйвера от мелкософта не будут задействованы, так и ограничит возможности рамками SunJDBCODBCDriver хотя возможности нативного драйвер написанного мелкософтом намного превосходят его. А это только один момент, второй это то что на linux/unix/solaris нет ODBC, и решение этого трабла приведет к еще одному уровню косвенности. Хотя ты конечно на этом форуме авторитет и тебе выбирать какие решения более оптимальные и масштабируемые, но я с тобой категорически несогласен потому как windows must die.