DataSource lub ConnectionPoolDataSource dla zasobów JDBC serwera aplikacji

Question

Podczas tworzenia pul połączeń JDND JDBC na serwerze aplikacji zawsze określałem typ jako javax.sql.ConnectionPoolDataSource. Nigdy nie zastanawiałem się nad tym zbyt często, ponieważ zawsze wydawało mi się, że preferuję łączone połączenia bez połączenia.

Jednak patrząc na niektóre przykłady (specifically for Tomcat) zauważyłem, że określają one javax.sql.DataSource. Ponadto wydaje się, że istnieją ustawienia dla maxIdle i maxWait, które sprawiają wrażenie, że te połączenia są również łączone. Glassfish pozwala również na te parametry niezależnie od wybranego typu źródła danych.

• Czy javax.sql.DataSource jest połączone na serwerze aplikacji (lub w kontenerze serwletów)?
• Jakie (jeśli jakiekolwiek) są zalety wyboru javax.sql.ConnectionPoolDataSource przez javax.sql.DataSource (lub odwrotnie)?

Answer 1

Tak, Tomcat domyślnie używa buforowania Apache DBCP dla źródeł danych zdefiniowanych jako zasoby kontekstu JNDI.

Z dokumentacją w http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html#JDBC_Data_Sources

Uwaga - wsparcie domyślne źródło danych w Tomcat bazuje na puli połączeń DBCP z Commons projektu. Można jednak użyć innej puli połączeń niż , która implementuje javax.sql.DataSource, przez , pisząc własną fabrykę zasobów , zgodnie z opisem poniżej.

Kopanie Tomcat 6 źródła ujawniły, że uzyskują oni fabrykę połączeń w ten sposób (w przypadku, gdy nie określono „Fabryka” atrybut własne za pomocą kontekstowego):

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

And org.apache.tomcat .dbcp.dbcp.BasicDataSourceFactory który implementuje javax.naming.spi.ObjectFactory dba o tworzenie instancji obiektu DataSource: 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

widzę tworzą wystąpień org.apache.tomcat.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

Co dziwne, ta klasa nie implementuje ConnectionPoolDataSource się, ani nie org.apache.tomcat.dbcp.dbcp.PoolingDataSource, że wróciła wewnętrznie przez 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

Więc przypuszczam po skonfigurowaniu DataSources jak javax.sql.ConnectionPoolDataSource użyłeś również pewnej niestandardowej fabryki (to tylko przypuszczenie, ale przypuszczam, że w przeciwnym razie miałbyś wyjątki odrzutu klasy w Tomcat, ponieważ ich łączenie w rzeczywistości nie zapewnia instancji javax.sql.ConnectionPoolDataSource, tylko javax.sql. Źródło danych).

W związku z tym, aby odpowiedzieć na pytania dotyczące zalet lub wad konkretnego przypadku, należy porównać system Apache DBCP z mechanizmem łączenia w fabryce DataSource, w zależności od tego, której używano.

Answer 2

moim rozumieniu jest to, że jedynym celem ConnectionPoolDataSource jest zapewnienie dostępu do PooledConnection który implementuje natywną łączenie przez sterownik JDBC. W tym przypadku serwer aplikacji może implementować łączenie połączeń przy użyciu tego natywnego interfejsu.

Podczas korzystania z prostego DataSource, serwer aplikacji używa własnej puli zamiast natywnej.

Nie można określić, które podejście jest najlepsze.

Answer 3

chodzi o docs Java zawiera ona następująco:

DataSource Java 7 API

interfejsu DataSource jest realizowany przez sprzedawcę kierowcy. Istnieją trzy rodzaje wdrożeń:

Podstawowe wdrożeniowe - wytwarza standardowego obiektu Connection

realizacji puli połączeń - tworzy obiekt połączenia automatycznie udziału w puli połączeń. Ta implementacja działa z menedżerem puli połączeń średniego poziomu.

Implementacja transakcji rozproszonych - tworzy obiekt połączenia, który może być używany do transakcji rozproszonych i prawie zawsze uczestniczy w puli połączeń. Ta implementacja działa z menedżerem transakcji warstwy pośredniej i prawie zawsze z menedżerem łączenia pul połączeń.

PooledConnection Java 7 API

programista aplikacji nie korzysta z interfejsu PooledConnection bezpośrednio; jest raczej wykorzystywany przez infrastrukturę klasy średniej, która zarządza łączeniem połączeń.

Gdy aplikacja wywołuje metodę DataSource.getConnection, zwraca obiekt połączenia. Jeśli wykonywane jest łączenie połączeń, ten obiekt połączenia jest w rzeczywistości uchwytem dla obiektu PooledConnection, który jest połączeniem fizycznym.

Menedżer puli połączeń, zwykle serwer aplikacji, utrzymuje pulę PooledConnection obiektów ....

Więc w końcu po prostu użyć DataSource i Connection klas i nigdy PooledConnection/ConnectionPoolDataSource, jeśli jesteś szczęśliwym i normalnym programistą.

Jeśli wdrażanie serwera aplikacji to inna historia ...