Источник данных или ConnectionPoolDataSource для ресурсов JDBC сервера приложений

при создании пулов соединений JNDI JDBC на сервере приложений я всегда указывал тип как javax.sql.ConnectionPoolDataSource. Я никогда не думал об этом слишком много, поскольку всегда казалось естественным предпочесть объединенные связи не-объединенным.

однако, глядя на некоторые примеры (специально для Tomcat) Я заметил, что они указать javax.sql.DataSource. Кроме того, кажется, есть настройки для maxIdle и maxWait создается впечатление, что эти соединения объединены в пул как что ж. Glassfish также позволяет эти параметры независимо от типа выбранного источника данных.

  • Are javax.sql.DataSource объединен в пул на сервере приложений (или в контейнере сервлетов)?
  • Какие (если есть) преимущества есть для выбора javax.sql.ConnectionPoolDataSource над javax.sql.DataSource (или наоборот)?
23
application-server configuration connection-pooling database java

3 ответов

да, Tomcat использует пул Apache DBCP по умолчанию для источников данных, определенных как ресурсы контекста JNDI.

из документации по http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html#JDBC_Data_Sources

Примечание-поддержка источника данных по умолчанию в Tomcat базируется на DBCP пул соединений с Викисклада проект. Однако, возможно используйте любой другой пул соединений, который реализующий javax.язык SQL.Источник, от написании собственных ресурсов фабрика, как описано ниже.

источники Digging Tomcat 6 показали, что они получают фабрику соединений таким образом (в случае, если вы не указываете свой собственный атрибут "factory" контекста):

ObjectFactory factory = (ObjectFactory)Class.forName(System.getProperty("javax.sql.DataSource.Factory", "org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory")).newInstance();

и org.апаш.кот.dbcp.dbcp.BasicDataSourceFactory, реализующий javax.называющий.спи.ObjectFactory заботится о создании источника данных экземпляры: http://www.jarvana.com/jarvana/view/org/apache/tomcat/tomcat-dbcp/7.0.2/tomcat-dbcp-7.0.2-sources.jar!/org/apache/tomcat/dbcp/dbcp/BasicDataSourceFactory.java?format=ok

Я вижу, что они создают экземпляры org.апаш.кот.dbcp.dbcp.BasicDataSource: http://www.jarvana.com/jarvana/view/org/apache/tomcat/tomcat-dbcp/7.0.2/tomcat-dbcp-7.0.2-sources.jar!/org/apache/tomcat/dbcp/dbcp/BasicDataSource.java?format=ok

странно достаточно того, этот класс не реализует сам ConnectionPoolDataSource, как и org.апаш.кот.dbcp.dbcp.PoolingDataSource, который возвращается внутренне BasicDataSource http://www.jarvana.com/jarvana/view/org/apache/tomcat/tomcat-dbcp/7.0.2/tomcat-dbcp-7.0.2-sources.jar!/org/apache/tomcat/dbcp/dbcp/PoolingDataSource.java?format=ok

поэтому я предполагаю, когда вы настроили свои источники данных как javax.язык SQL.ConnectionPoolDataSource вы также использовали некоторые пользовательские фабрика (это просто предположение, но я полагаю, что в противном случае у вас были бы исключения класса в Tomcat, так как их объединение на самом деле не предоставляет экземпляры javax.язык SQL.ConnectionPoolDataSource, только javax.язык SQL.Источник данных).

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

8

насколько я понимаю, это единственная цель ConnectionPoolDataSource - дать доступ к PooledConnection, который реализует уроженца объединение драйвером JDBC. В этом случае сервер приложений может реализовать объединение соединений с помощью этого собственного интерфейса.

при использовании simple DataSource, appserver использует собственный пул вместо собственного.

не могу сказать, какой подход лучше.

5

Что касается документов Java, он содержит это:

источник данных Java 7 API

интерфейс источника данных реализован поставщиком драйверов. Существует три типа реализаций:

базовая реализация -- создает стандартный объект соединения

реализация пула соединений -- создает объект соединения, который будет автоматически участвовать в пуле соединений. Эта реализация работает с менеджер пула соединений среднего уровня.

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

PooledConnection Java 7 API

An application programmer не использует в соединении pooledconnection интерфейс напрямую; скорее, он используется инфраструктурой среднего уровня,которая управляет объединением соединений.

когда приложение вызывает метод DataSource.getConnection, он возвращает объект соединения. если выполняется объединение пулов соединений, этот объект соединения фактически является дескриптором объекта PooledConnection, что является физическим соединением.

менеджер пула соединений, как правило, сервер приложений, поддерживает пул PooledConnection объекты ....

Так что в конце концов вы просто используете источник и подключение классы и никогда не PooledConnection / ConnectionPoolDataSource, если вы счастливый и нормальный программист.

Если реализуют сервер приложений, это другая история...

5