| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java: Общие вопросы > Что лучше, много Statement 1 Connection, или пул C |
| Автор: UnicornMirage 23.2.2006, 20:43 |
| Здавсствуйте.. Сейчас решаю задачу: как лучше с точки зрения хорошего стиля программирования, производительности и т.п. реализовать многопользовательский доступ к БД через JDBC? есть 2 варианта: 1) существует одно соединение (connection) с БД и для него создается один PreparedStatement в который посылаются запросы от разных пользователей 2) создавать соединение и PreparedStatement для каждого пользователя и помещать соединение в пул соединений реализовал 2 варианта но пока не могу дать оценку, хочется услышать мнение экспертов. |
| Автор: Nobody 23.2.2006, 23:39 |
| Я бы не парился до тех пор, пока это не станет самым узким местом в приложении. |
| Автор: COVD 24.2.2006, 00:01 | ||
Согласен. Можно и с одним соединением работать. А преимущества пула - это еще надо убедиться, что они есть, потому что зависит от многих факторов. |
| Автор: LSD 24.2.2006, 00:52 |
| Все сильно зависит от частоты запросов, их характера и СУБД. С одной стороны каждый дополнительный коннект к базе требует дополнительных ресурсов от сервера, с другой стороны если запрос нуждается в блокировках строк, то несколько сессий могут работать быстрее если они блокируют разные строки. И т.д., за и против хватает. Если для тебя этот вопрос важен, то напиши тестик и проверь на своей конкретной задаче. |
| Автор: carper 26.2.2006, 10:32 |
| В принципе, соединение на пользователя дает больше свободы в индивидуальной настройке параметров сессии для конкретного пользователя. Также администратору базы гораздо проще разобраться с проблемами (да и завершить конкретную сессию), если соблюдается принцип 1 пользователь = 1 коннект. Как тут уже писали, многое зависит от конретного приложения, в общих чертах, думаю, что правильнее будет для длительных сессий все же выбрать вариант с одним коннектом на одного пользователя (при необходимости можно задействовать MTS, либо готовые пулы соединений), а для разной шелупони по обслуживанию разовых web users можно использовать и один коннект (лучше опять же выделить небольшой пул). Пул соединений лучше использовать готовый, нет смысла писать самому. P.S. А вот Statement or PreparedStatement иметь один несколько странно - это что же получается, конкуренция за resultSet, как минимум? Я бы не стал ограничивать ( в разумных пределах) их кол-во, лучше не забывайте их закрывать, причем отдельно! ResultSet и потом Statements (не верьте SUN, что достаточно просто закрыть Statement). |
| Автор: UnicornMirage 26.2.2006, 15:57 | ||
| большое спасибо за ответы! прочитал ваши сообщения, после чего - статью http://lib.juga.ru/article/articleprint/162/-1/68/ и понял что шел по неверному пути, наступая на грабли. еще пару вопросов:
-- что такое MTS? (в форуме по java не нашел такого ключевого слова) -- готовые пулы соединений (я использую mysql-connector-java-3.1.10-bin.jar) - ссылку чтобы прочитать.. |
| Автор: carper 26.2.2006, 18:41 |
| UnicornMirage Sorry, я забыл уточнить. MTS (Multi-threaded Server) - это термин из Oracle, грубо говоря, он занимается как раз управлением пулом открытых соединений прозрачно для пользователей и не требует от разработчика выполнения не свойственных ему задач, т.к. IMHO управлять пулом соединений разумнее на стороне DBA. Готовые пулы, это просто коммерческие и freeware products, которые и реализуют пулы соединений. Например, commons-dbcp package from http://jakarta.apache.org/commons/dbcp/ or Excalibur from http:// excalibur.apache.org/. Впрочем, и самому написать проблема не больно велика, зависит только от глубины проработки и от того, что данные классы несут довольно серьезную ответственность за нормальную работу всех приложений, к ним обращающихся. P.S. Почитал статью "Connection Pool", что-то в этом роде и можно наваять самому, но думаю, что для серьезного использования там кое-чего не хватает (по-видимому, автор просто не стал перегружать статью деталями и подробностями, а то можно было залезть в порядочные дебри). |