Error preloading the connection pool

Русские Блоги

HowTo configure the C3P0 connection pool

Configuration
Here is a sample of C3P0 configuration. This is an extract of hibernate.cfg.xml:

You also can set extra c3p0 properties using c3p0.properties. Put this file in the classpath (WEB-INF/classes for example), but be careful, the previous values will be overridden by Hibernate whether set or not (see below for more details). For more information on C3P0 configuration, please have a look at http://sourceforge.net/projects/c3p0 and unzip the download, there is a doc folder where you’ll find everything you need.

For more on hibernate/c3p0 issues, see c3p0’s docs at http://www.mchange.com/projects/c3p0/index.html#appendix_d

Parameters
c3p0 is very tunable, and offers a somewhat bewildering array of configuration parameters. For the complete list, see http://www.mchange.com/projects/c3p0/index.html#appendix_a

Here are a subset of the most important features:

initialPoolSize C3P0 default: 3

minPoolSize Must be set in hibernate.cfg.xml (or hibernate.properties), Hibernate default: 1

maxPoolSize Must be set in hibernate.cfg.xml (or hibernate.properties), Hibernate default: 100

idleTestPeriod Must be set in hibernate.cfg.xml (or hibernate.properties), Hibernate default: 0

If this is a number greater than 0, c3p0 will test all idle, pooled but unchecked-out connections, every this number of seconds.

timeout Must be set in hibernate.cfg.xml (or hibernate.properties), Hibernate default: 0

The seconds a Connection can remain pooled but unused before being discarded. Zero means idle connections never expire.

maxStatements Must be set in hibernate.cfg.xml (or hibernate.properties), Hibernate default: 0

The size of c3p0’s PreparedStatement cache. Zero means statement caching is turned off.

propertyCycle Must be set in c3p0.properties, C3P0 default: 300

Maximum time in seconds before user configuration constraints are enforced. c3p0 enforces configuration constraints continually, and ignores this parameter. It is included for JDBC3 completeness.

acquireIncrement Must be set in hibernate.cfg.xml (or hibernate.properties), Hibernate default: 1

Determines how many connections at a time c3p0 will try to acquire when the pool is exhausted.

testConnectionOnCheckout Must be set in c3p0.properties, C3P0 default: false

Don’t use it, this feature is very expensive. If set to true, an operation will be performed at every connection checkout to verify that the connection is valid. A better choice is to verify connections periodically using c3p0.idleConnectionTestPeriod.

autoCommitOnClose Must be set in c3p0.properties, C3P0 default: false

The JDBC spec is unfortunately silent on what should happen to unresolved, pending transactions on Connection close. C3P0’s default policy is to rollback any uncommitted, pending work. (I think this is absolutely, undeniably the right policy, but there is no consensus among JDBC driver vendors.) Setting autoCommitOnClose to true causes uncommitted pending work to be committed, rather than rolled back on Connection close. [Note: Since the spec is absurdly unclear on this question, application authors who wish to avoid bugs and inconsistent behavior should ensure that all transactions are explicitly either committed or rolled-back before close is called.]

forceIgnoreUnresolvedTransactions Must be set in c3p0.properties, C3P0 default: false

Strongly disrecommended. Setting this to true may lead to subtle and bizarre bugs. This is a terrible setting, leave it alone unless absolutely necessary. It is here to work around broken databases / JDBC drivers that do not properly support transactions, but that allow Connections’ autoCommit flags to be set to false regardless. If you are using a database that supports transactions «partially» (this is oxymoronic, as the whole point of transactions is to perform operations reliably and completely, but nevertheless, such databases exist), if you feel comfortable ignoring the fact that Connections with autoCommit == false may be in the middle of transactions and may hold locks and other resources, you may turn off c3p0’s wise default behavior, which is to protect itself, as well as the usability and consistency of the database, by either rolling back (default) or committing (see c3p0.autoCommitOnClose above) unresolved transactions. This should only be set to true when you are sure you are using a database that allows Connections’ autoCommit flag to go to false, but that it offers no other meaningful support of transactions. Otherwise setting this to true is just a bad idea.

numHelperThreads Must be set in c3p0.properties, C3P0 default: 3

c3p0 is very asynchronous. Slow JDBC operations are generally performed by helper threads that don’t hold contended locks. Spreading these operations over multiple threads can significantly improve performance by allowing multiple operations to be performed simultaneously.

factoryClassLocation Must be set in c3p0.properties, C3P0 default: null

DataSources that will be bound by JNDI and use that API’s Referenceable interface to store themselves may specify a URL from which the class capable of dereferencing a them may be loaded. If (as is usually the case) the c3p0 libraries will be locally available to the JNDI service, leave this set to null.

(see http://forum.hibernate.org/viewtopic.php?t=934779 for more details)

If you want to get rid of the C3P0 status that is printed, by default, when hibernate starts, you need to recompile C3P0 sources after changing com.mchange.v2.c3p0.Debug.DEBUG to false.

This is a public static final field that cannot be changed by configuration files.

Hibernate’s C3P0ConnectionProvider explicitly sets 7 c3p0 configuration properties, based on your hibernate configuration, overriding any configuration you may have set in a c3p0.properties file. If you are using Hibernate’s C3P0ConnectionProvider you must set the following properties in your hibernate configuration, using hibernate-specific configuration keys. All other properties must be defined as usual in a c3p0.properties file. This is confusing, and will hopefully be simplified some time in the future, but for now.

The following properties must be set in your hibernate configuration:

Remember — these, and only these, properties must be defined in your hibernate configuration, or else they will be set to hibernate-specified defaults. All other configuration properties that you wish to set should be defined in a c3p0.properties file. (See «Overriding c3p0 defaults via c3p0.properties».)

Источник

Русские Блоги

Сценарный анализ исходного кода DBCP источника данных JDBC

Предыдущее сообщение в блогеОт JDBC к commons-dbutils Я однажды написал, что есть решение для получения соединений с базой данных, и это источник данных. В отрасли используется множество распространенных решений для источников данных с открытым исходным кодом, и DBCP является одним из них.Сегодня я пытаюсь интерпретировать это решение с точки зрения исходного кода.

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

1. Общее использование DBCP

На самом деле использовать DBCP очень просто: обычно нужно создать BasicDataSource, затем установить параметры и вызвать метод getConnection (), когда вам нужно установить соединение. код показан ниже:

Где driverClass — это имя класса драйвера базы данных, username — это имя пользователя базы данных, pswd — пароль базы данных, connectURI — это URI для подключения к базе данных, а initialSize — это количество соединений, созданных во время инициализации.

maxActive — максимальное количество активных соединений, maxIdle — Максимальное количество незанятых соединений, maxWait — максимальное время ожидания (мс) при установлении соединения.

2. Анализ исходного кода описанных выше сценариев.

В разработке BasicDataSource И при настройке параметров для него (первый шаг выше) по сути BasicDataSource Построение не завершено.Только при первом вызове метода getConnection будет построен реальный источник данных, как видно из кода:

Из исходного кода видно, что источник данных должен быть создан до получения соединения, а созданный источник данных будет использоваться как BasicDataSource Внутренний источник данных предоставляет услуги для получения подключений. Ниже для этого createDataSource() Метод для объяснения, сначала посмотрите его исходный код:

Как видно из исходного кода, createDataSource() Этот метод использует 7 шагов для пошагового построения источника данных. Вот подробные шаги:

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

2. Позвоните createConnectionFactory() Создайте фабрику соединений JDBC driverConnectionFactory, эта фабрика использует драйвер базы данных для создания самого низкого соединения JDBC

3. Позвоните createConnectionPool() Создайте пул соединений, используемый источником данных. Как следует из названия, пул соединений является местом для кэширования соединений JDBC.

4. При необходимости установите буферный пул оператора, обычно это не требуется.

5. Позвоните createPoolableConnectionFactory Создайте PoolableConnection Фабрика, эта фабрика, использует вышеуказанный driverConnectionFactory для создания базового соединения JDBC, а затем обертывает PoolableConnection ,Вот этот PoolableConnection Отношение «один ко многим» устанавливается с пулом подключений, то есть существует несколько PoolableConnection , Каждый PoolableConnection Связаны с одним и тем же пулом соединений, поэтому преимущество заключается в упрощении таблицы PoolableConnection Подробно поведение метода close будет проанализировано позже.

6. Позвоните createDataSourceInstance () создает внутренний источник данных

7. Добавить в пул подключений PoolableConnection

После перечисленных выше 7 шагов формируется источник данных, здесь ясно, что суть источника данных — это пул соединений + соединение + стратегия управления. Ниже мы подробно разберем каждый шаг.

2.1 Процесс создания фабрики соединений JDBC driverConnectionFactory

Сначала перейдите к исходному коду:

Что делает вышеуказанная серия кодов? Фактически, выполняются две вещи: 1. Получить драйвер базы данных. 2. Использовать драйвер и параметры (URL-адрес, имя пользователя, пароль) для создания фабрики. После того, как фабрика построена, вы можете создавать соединения, и создание этого соединения фактически осуществляется путем управления и настройки. Ниже представлена ​​диаграмма последовательности этого процесса.

При получении драйвера используются два метода: один — Class.forName, другой — DriverManager.getDriver (url), после получения драйвера получить имя пользователя, пароль и параметры URL и, наконец, создать DriverConnectionFactory ,и DriverConnectionFactory Способ создания соединения можно увидеть из исходного кода:

Он определяется драйверами и параметрами конфигурации.

2.2 Процесс создания пула соединений

Сначала посмотрите исходный код:

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

2.3 Создание пула буферов операторов

Вообще говоря, оператор не является тяжелым объектом, и ресурсы, потребляемые в процессе создания, не такие тяжелые, как соединения JDBC, поэтому нет необходимости создавать пул буферов.Для простоты мы не будем анализировать это здесь.

2.4 Создание PoolableConnectionFactory

Этот шаг представляет собой процесс соединения вверх и вниз. Продолжать Он предназначен для использования фабрики соединений и пула соединений, созданных в двух вышеупомянутых частях, для создания PoolableConnectionFactory, Qixia Он предназначен для подготовки к последующему добавлению соединений в пул соединений.

Давайте сначала загрузим статическую диаграмму отношений классов:

Затем исходный код:

Как видите, при создании PoolableConnectionFactory необходимо использовать ранее созданный driverConnectionFactory И пул соединений connectionPool , Что делает этот конструктор в первую очередь?

Он хранит реальную фабрику соединений JDBC и пул соединений внутри, а затем с помощью предложения _pool.setFactory( this ); Установить себя в пул соединений. Эта строка кода очень важна. Чтобы понять эту строку кода, вам сначала нужно понять общий пул GenericObjectPool добавляет внутренние элементы Общий метод, да, то есть фабрика должна быть передана. GenericObjectPool вызывает метод addObject () при добавлении внутренних элементов. Фактически, он вызывает фабричный метод makeObejct () для создания элементов, а затем добавляет их в свой собственный пул. _pool.setFactory( this ) Этот код действительно работает Без него добавление соединений в пул соединений было бы невозможно без него.

После создания фабрики появится validateConnectionFactory(connectionFactory); Функция этого метода заключается только в том, чтобы убедиться, что соединение с базой данных доступно, см. Код:

Сначала используйте метод makeObject для создания подключения, а затем выполните соответствующую проверку (то есть попробуйте выполнить его с помощью некоторого инициализирующего sql, чтобы увидеть, можете ли вы подключиться к базе данных), а затем уничтожьте соединение. Нет подключения к пул соединений здесь, настоящее дополнение Connect сзади, но сначала мы можем увидеть, что делает метод makeObject, на следующей диаграмме последовательности.

Ниже представлена ​​диаграмма последовательности всего процесса:

Как видно из рисунка, общая схема работы метода makeObject: driverConnectionFactory Получите базовое соединение там, инициализируйте проверку, а затем создайте PoolableConnection. При создании этого PoolableConnection установите PoolableConnection Связанное с пулом соединений, действительно достигается связь «один ко многим» между пулом соединений и соединением, что также является изменением PoolableConnection Метод close обеспечивает удобство.

Вот исходный код метода makeObject:

среди них PoolableConnection Конструктор выглядит следующим образом:

Внутренне связанная с пулом соединений, роль этого пула соединений отражена в PoolableConnection В методе закрытия:

Одна линия _pool.returnObject (this) указывает, что на самом деле он не закрыт, но возвращен в пул соединений.

На этом этапе создается PoolableConnectionFactory, и он использует driverConnectionFactory Чтобы создать базовое соединение, с помощью makeObject для создания PoolableConnection ,Вот этот PoolableConnection Через ассоциацию с connectionPool для достижения роли изменения метода закрытия, когда PoolableConnectionFactory При создании он был установлен как фабричный класс connectionPool ,Позади connectionPool Будет использовать эту фабрику для производства PoolableConnection , И все сгенерировано PoolableConnection Связаны с connectionPool, вы можете скачать с connectionPool Выньте или верните connectionPool . Далее давайте посмотрим, как инициализировать connectionPool 。

2.5 Создание источника данных и инициализация пула соединений

Соответствующий код выглядит следующим образом:

Давайте посмотрим createDataSourceInstance();

Фактически, это создание PoolingDataSource в качестве базового реального источника данных.Этот PoolingDataSource относительно прост и не будет здесь подробно описываться.

Далее идет цикл for, вызывая connectionPool.addObject(); Чтобы добавить соединение с базой данных в пул соединений, следующая диаграмма последовательности:

Видно, что здесь работает PoolableConnectionFactory, созданная в 2.4, addObject зависит от makeObject, и makeObject также представлен выше.

Пока что источник данных создан, и в пуле подключений есть доступные подключения, и каждое подключение связано с пулом подключений, что меняет поведение закрытия. В настоящее время работает BasicDataSource.При вызове getConnection он фактически вызывает getConnection базового источника данных, а базовый источник данных фактически является соединением, полученным из пула соединений.

Ядро всего источника данных на самом деле состоит из трех частей: первая — это пул соединений, который здесь отражен в общем пуле. GenericObjectPool , Он отвечает за кэширование и управление подключениями, и все стратегии конфигурации управляются им. Вторая связь, здесь связь PoolableConnection Конечно, он инкапсулирует базовое соединение. Третий — это связь между пулом соединений и соединением, которая здесь представлена ​​как взаимные ссылки «один ко многим». Построение источника данных — это построение пула соединений, соединения и взаимосвязи между пулом соединений и соединением.Если вы овладеете этими точками, вы сможете в основном освоить построение источника данных.

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

Наконец, я проанализировал DBCP версии 1.4, а последняя версия — 2.X. Необходимо внести серьезные изменения во всю структуру кода. Я проанализирую ее еще раз, когда у меня будет возможность. Кроме того, действительно сложной частью источника данных является кеширование и управление подключением. Эта часть решается общим пулом. Я обязательно проанализирую это, когда у меня будет возможность.

Источник

Теги:  java  mysql

BasicDataSource dbcp = new BasicDataSource();

dbcp.getConnection();

Интеллектуальная рекомендация

Вам также может понравиться

Ошибка предварительной загрузки пула соединений

Could not get JDBC Connection; nested exception is org.apache.commons.dbcp.SQLNestedException: Error preloading the connection pool

Ответы (1)