Параметры объединения пула с JDBC: DBCP vs C3P0

Ответ 1

DBCP устарел, а не производственный. Некоторое время назад мы провели внутренний анализ этих двух, создав тестовый прибор, который генерировал нагрузку и concurrency против двух, чтобы оценить их пригодность в реальных условиях жизни.

DBCP последовательно генерировал исключения в нашем тестовом приложении и изо всех сил пытался достичь уровня производительности, который C3P0 был более чем способен обрабатывать без каких-либо исключений.

C3P0 также надежно обрабатывает разъединения DB и прозрачные повторные подключения при возобновлении, тогда как DBCP никогда не восстанавливал соединения, если связь была выведена из-под нее. Хуже того, DBCP возвращал объекты Connection в приложение, для которого был поврежден базовый транспорт.

С тех пор мы использовали C3P0 в 4 основных приложениях с большой нагрузкой и никогда не оглядывались назад.

ОБНОВЛЕНИЕ: Оказывается, после многих лет сидения на полке, люди Apache Commons взяли DBCP из покоя, и теперь он снова активно развивается. Таким образом, мой оригинальный пост может быть устаревшим.

Сказано, что я еще не испытал эту новую обновленную производительность библиотеки и не слышал, что она де-факто в любой новой платформе приложений.

Ответ 2

Я приглашаю вас попробовать BoneCP - бесплатно, с открытым исходным кодом и быстрее доступных альтернатив (см. раздел сравнения).

Отказ от ответственности: я автор, поэтому вы можете сказать, что я предвзятый: -)

ОБНОВЛЕНИЕ: По состоянию на март 2010 года, все еще примерно на 35% быстрее, чем новый перезаписанный пул Apache DBCP ( "tomcat jdbc" ). См. Ссылку динамического сравнения в разделе эталона.

Обновление № 2: (декабрь 13). Через 4 года на вершине появился гораздо более быстрый конкурент: https://github.com/brettwooldridge/HikariCP p >

Обновление # 3: (сентябрь '14) Пожалуйста, подумайте, что BoneCP будет устаревшим в этот момент, рекомендуем перейти на HikariCP.

Обновление № 4: (апрель '15) - я больше не владею доменом jolbox.com, но новый владелец сохранил старое содержимое, поэтому будьте осторожны.

Ответ 3

У меня были проблемы с DBCP, когда время соединения заканчивается, поэтому я опробовал c3p0. Я собирался выпустить это на производство, но затем начал тестирование производительности. Я обнаружил, что c3p0 работает ужасно. Я не мог настроить его на полноценную работу. Я нашел его в два раза медленнее, чем DBCP.

Затем я попробовал пул соединений Tomcat.

Это было в два раза быстрее, чем c3p0, и исправил другие проблемы, которые я имел с помощью DBCP. Я потратил много времени на исследование и тестирование трех бассейнов. Мой совет, если вы развертываете Tomcat, - это использовать новый пул Tomcat JDBC.

Ответ 4

Что касается проблемы автосоединения с DBCP, попытались ли использовать следующие 2 параметра конфигурации?

validationQuery="Some Query"

testOnBorrow=true

Ответ 5

Используют DBCP уже пару лет в производстве. Он стабилен, выживает перезагрузка сервера БД. Просто настройте его правильно. Это требует только нескольких параметров, которые нужно указать, поэтому не ленитесь. Вот фрагмент из нашего производственного кода системы, в котором перечислены параметры, которые мы явно задали, чтобы заставить его работать:

DriverAdapterCPDS driverAdapterCPDS = new DriverAdapterCPDS();
driverAdapterCPDS.setUrl(dataSourceProperties.getProperty("url"));
driverAdapterCPDS.setUser(dataSourceProperties.getProperty("username"));
driverAdapterCPDS.setPassword(dataSourceProperties.getProperty("password"));
driverAdapterCPDS.setDriver(dataSourceProperties.getProperty("driverClass"));

driverAdapterCPDS.setMaxActive(Integer.valueOf(dataSourceProperties.getProperty("maxActive")));
driverAdapterCPDS.setMaxIdle(Integer.valueOf(dataSourceProperties.getProperty("maxIdle")));
driverAdapterCPDS.setPoolPreparedStatements(Boolean.valueOf(dataSourceProperties.getProperty("poolPreparedStatements")));

SharedPoolDataSource poolDataSource = new SharedPoolDataSource();
poolDataSource.setConnectionPoolDataSource(driverAdapterCPDS);
poolDataSource.setMaxWait(Integer.valueOf(dataSourceProperties.getProperty("maxWait")));
poolDataSource.setDefaultTransactionIsolation(Integer.valueOf(dataSourceProperties.getProperty("defaultTransactionIsolation")));
poolDataSource.setDefaultReadOnly(Boolean.valueOf(dataSourceProperties.getProperty("defaultReadOnly")));
poolDataSource.setTestOnBorrow(Boolean.valueOf(dataSourceProperties.getProperty("testOnBorrow")));
poolDataSource.setValidationQuery("SELECT 0");

Ответ 6

Другой альтернативой является HikariCP.

Вот сравнение benchmark

Ответ 7

Вот несколько статей, которые показывают, что DBCP имеет значительно более высокую производительность, чем C3P0 или Proxool. Также в моем собственном опыте c3p0 имеет некоторые приятные функции, такие как подготовленный пул операторов и более настраиваемый, чем DBCP, но DBCP явно быстрее в любой среде, в которой я ее использовал.

Разница между dbcp и c3p0? Абсолютно ничего! (Блог разработчиков Sakai)   http://blogs.nyu.edu/blogs/nrm216/sakaidelic/2007/12/difference_between_dbcp_and_c3.html

См. также статью JavaTech "Развертывание пула соединений" в комментариях к сообщению в блоге.

Ответ 8

Другая альтернатива, Proxool, упоминается в в этой статье.

Возможно, вам удастся выяснить, почему Hibernate связывает c3p0 с его реализацией пула соединений по умолчанию?

Ответ 9

К сожалению, все они устарели. Недавно был обновлен DBCP, два других - 2-3 года, с многочисленными выдающимися ошибками.

Ответ 10

Dbcp - это готовая продукция, если она настроена правильно.

Он, например, используется на веб-сайте торговли 350000 посетителей в день и с пулами из 200 подключений.

Он обрабатывает очень хорошие тайм-ауты при правильной настройке.

Версия 2 идет о прогрессе, и у нее есть фон, который делает его надежным, поскольку многие Проблемы производства были решены.

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

Тесты производительности, выполняемые пулом tomcat jdbc, показывают, что он имеет лучшую производительность, чем cp30.

Ответ 11

Только что потратил полтора дня с DBCP. Несмотря на то, что я использую последнюю версию DBCP, я столкнулся с теми же проблемами, что и j pimmel. Я бы вообще не рекомендовал DBCP, особенно, когда он удаляет соединения из пула, когда БД уходит, его невозможность повторно подключиться, когда БД возвращается, и его неспособность динамически добавлять объекты подключения обратно в пул (он вечно вешает сообщение сокета JDBCconnect для ввода/вывода)

Теперь я переключаюсь на C3P0. Я использовал это в предыдущих проектах, и он работал и выполнялся как прелесть.

Ответ 12

c3p0 хорош, когда мы используем проекты mutithreading. В наших проектах мы использовали одновременное выполнение нескольких потоков с использованием DBCP, тогда мы получили таймаут соединения, если мы использовали больше выполнения потоков. Итак, мы пошли с конфигурацией c3p0.

Ответ 13

Хорошей альтернативой, которая проста в использовании, является DBPool.

"Утилита объединения пула на базе Java, поддерживающая истечение времени, кэширование инструкций, проверка соединения и простая настройка с помощью диспетчера пулов".

http://www.snaq.net/java/DBPool/

Ответ 14

Мы столкнулись с ситуацией, когда нам нужно было ввести пул соединений, и у нас было 4 варианта перед нами.

• DBCP2
• C3P0
• Tomcat JDBC
• HikariCP

Мы провели несколько тестов и сравнений, основанных на наших критериях, и решили пойти на HikariCP. Прочитайте эту статью, которая объясняет, почему мы выбрали HikariCP.

Ответ 15

Чтобы лучше реализовать C3P0, проверьте этот ответ

C3P0:

Для корпоративного приложения C3P0 - лучший подход. C3P0 - это простая в использовании библиотека для расширения традиционных драйверов JDBC на основе DriverManager с JNDI-привязанными DataSources, включая DataSources, которые реализуют Connection and Statement Pooling, как описано в спецификации jdbc3 spec и jdbc2 std. C3P0 также надежно обрабатывал разъединения DB и прозрачные повторные подключения при возобновлении, тогда как DBCP никогда не восстанавливал соединения, если связь была выведена из-под нее.

Поэтому именно поэтому c3p0 и другие пулы соединений также подготовили оператор caches-, что позволяет использовать код приложения, чтобы избежать всего этого. Заявления обычно хранятся в ограниченном пуле LRU, поэтому обычные заявления повторно используют экземпляр PreparedStatement.

Хуже того, DBCP возвращал объекты Connection в приложение, для которого был поврежден базовый транспорт. Общим вариантом использования c3p0 является замена стандартного пула соединений DBCP, включенного в Apache Tomcat. Часто программист сталкивается с ситуацией, когда соединения неправильно перерабатываются в пуле соединений DBCP, а c3p0 является ценной заменой в этом случае.

В текущих обновлениях C3P0 обладает некоторыми блестящими функциями. те приведены ниже:

ComboPooledDataSource dataSource = new ComboPooledDataSource();
dataSource.setMinPoolSize();
dataSource.setMaxPoolSize();
dataSource.setMaxIdleTime();
dataSource.setMaxStatements();
dataSource.setMaxStatementsPerConnection();
dataSource.setMaxIdleTimeExcessConnections();

Здесь max и min poolize определяют границы соединения, что означает, как минимальное и максимальное соединение будет выполняться этим приложением. MaxIdleTime() определяет, когда он освободит незанятое соединение.

DBCP:

Этот подход также хорош, но имеет некоторые недостатки, такие как тайм-аут соединения и повторное соединение. C3P0 хорош, когда мы используем mutithreading проекты. В наших проектах мы использовали одновременное выполнение нескольких потоков с использованием DBCP, тогда мы получили таймаут соединения, если мы использовали больше выполнения потоков. Итак, мы пошли с конфигурацией c3p0. Я бы вообще не рекомендовал DBCP, особенно, когда он удаляет соединения из пула, когда БД уходит, его невозможность повторно подключиться, когда БД возвращается, и его неспособность динамически добавлять объекты подключения обратно в пул (он вечно веет сообщение сокета JDBCconnect для ввода/вывода)

Благодаря :)

Ответ 16

моя рекомендация

hikari> друид> UCP> c3p0> DBCP

Он основан на том, что я тестировал - 20190202, в моей локальной тестовой среде (4 ГБ mac/mysql в докере/пуле minSize = 1, maxSize = 8), hikari может обслуживать 1024 потока x 1024 раза для получения соединений, среднее время для каждого потока до конца 1 или 2 миллиона секунд, в то время как c3p0 может обслуживать только 256 потоков x 1024 раза, а среднее время для каждого потока уже составляет 21 миллион секунд. (512 потоков не удалось).