Wygląda na to, że istnieje duże zamieszanie między tymi dwiema bibliotekami pul połączeń. Chcę wiedzieć, który z nich jest lepszy (jeśli w ogóle)?
Oto kilka kwestii, które chciałbym poruszyć ... Czy ktoś mógłby to zweryfikować?
Tomcat DBCP: używa domyślnego tomcat-dbcp.jar, który będzie obecny w twoim katalogu tomcat / lib. ty nie rób potrzebujesz bibliotek commons-dbcp.jar lub commons-pool.jar w swoim web-inf / lib. Sterownik DB powinien zostać umieszczony w tomcat / lib.
Klasa źródła danych Tomcat DBCP to
org.apache.tomcat.dbcp.dbcp.BasicDataSource. Commons Klasa danych DBCP jestorg.apache.commons.dbcp.BasicDataSource.Jedyną różnicę między tymi dwoma można znaleźć w ten blog. Nie wiem, czy informacje są poprawne, czy nie.
Oficjalna dokumentacja Tomcat wyraźnie wspomina, że większość klas została właśnie przemianowana i przepakowana.
Pytanie brzmi: który użyć, a który lepszy?
Odpowiedzi:
32 dla odpowiedzi nr 1Tomcat DBCP to po prostu przemianowana wersja Apache Commons DBCP z innym wewnętrznym prefiksem nazwy pakietu.
W czasie kompilacji Tomcat pobiera źródła Commons DBCP (wersja zależy od wersji Tomcat, na przykład Tomcat 7.0.27 używa Commons DBCP 1.4) i zastępuje nazwy pakietów (org.apache.commons -> org.apache.tomcat.dbcp) i buduje wynik jako tomcat-dbcp.jar.
Odbywa się to tak, że wewnętrzne pule JDBC Tomcat nigdy nie powodują konfliktu z możliwymi zastosowaniami klas Commons DBCP. Pozwala to uniknąć wielu potencjalnych problemów z ładowaniem klas.
Edytować: Pakiety „dbcp” dotyczą zarządzania źródłami danych. Dla implementacji czystej puli Commons DBCP zależy od Commons Pool (pakiet org.apache.commons.pool), ale w Tomcat implementacja puli została zastąpiona własną Tomcat Pula JDBC (pakiet org.apache.tomcat.jdbc.pool).
13 dla odpowiedzi nr 2
Wygląda na to, że istnieje duże zamieszanie między tymi dwiema bibliotekami pul połączeń. Chcę wiedzieć, który z nich jest lepszy (jeśli w ogóle)?
TL / DR: są takie same, nie używaj żadnego z nich.
Tomcat-dbcp jest oryginalnym przepakowaniem puli apache commons zawartej w dystrybucji Tomcat. Aby uniknąć konfliktu klas, zmieniono nazwę pakietu na org.apache.tomcat.dbcp.dbcp. *
W Tomcat 7 (od wersji 7.0.19 w lipcu 2011 r.) Dodatkowa pula połączeń została dołączona do domyślnego pakietu Tomcat (jako część tomcat-jdbc.jar) jako alternatywa dla przestarzałej implementacji wspólnych apache commons, o nazwie „Pula połączeń JDBC Tomcat”:
https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html
W tym artykule omówiono różnice między nimi:
http://vigilbose.blogspot.com/2009/03/apache-commons-dbcp-and-tomcat-jdbc.html
Krótkie podsumowanie, dlaczego nowa pula Tomcat jest lepsza:
- aktywnie wspierane
- znacznie mniejszy, łatwiejszy do zrozumienia i utrzymania (jeśli zależy ci na źródle)
- obsługuje wszystkie funkcje commons-dbcp + dodaje super przydatne funkcje, takie jak „initSQL”, „validationInterval”, „jdbcInterceptors” i inne
11 dla odpowiedzi nr 3
Starsze wersje Apache Commons DBCP (tj. wersja 1.2) miała pewne nieprzyjemne problemy z bezpieczeństwem nici w warunkach dużego obciążenia, przez co nie nadaje się do tego rodzaju użytkowania. Nie dziwi mnie, że ludzie Tomcat przerobili go, aby rozwiązać te problemy.
Rozumiem jednak, że Commons DBCP 1.4 rozwiązuje te problemy. Nie mogę tego potwierdzić osobiście, ale może to spowodować, że wersja Tomcat będzie zbędna.
Co ciekawe, SpringSource przepisał również Commons DBCP dla swojej przepakowanej wersji Tomcat (tc-Server) i twierdzą, że czerpią z tego duże korzyści w zakresie wydajności. Jednak nie mają otwartego źródła.
6 dla odpowiedzi № 4
Tomcat 7 nadal korzysta z DBCP. Główny powód może być ukryty w ich dokumentach Tomcat:
Apache Commons DBCP można skonfigurować dośledź je i odzyskaj porzucone połączenia z bazą danych. Nie tylko może je odzyskać, ale także wygeneruj ślad stosu dla kodu, który otworzył te zasoby i nigdy ich nie zamykałem.
Biblioteka puli jdbc Tomcat, może znacznie szybszajednoczesne scenariusze, ale nie można ich zamknąć i automatycznie wypuszcza instrukcje (które deweloper zapomniał zamknąć), co powoduje możliwe wycieki pamięci w niektórych sterownikach JDBC.
Jednak jednym z problemów z kodem DBCP jestmodel delegacji, którego używają, obecnie ich najnowsze wersje obsługują JDK 1.6 i nowsze. Wspieranie 1.7 oznacza zmianę co najmniej jednej czwartej ich klas, co było jednym z powodów, dla których powstała biblioteka puli JDBC.
UWAGA: Po dalszym badaniu pula JDBC ma sposób zamykania instrukcji otwierania po zamknięciu połączenia za pomocą StatementFinalizer przechwytujący.
4 dla odpowiedzi № 5
Oto lista zalet używania puli JDBC Tomcat zamiast commons-dbcp: http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
3 dla odpowiedzi № 6
Aby dodać tutaj: Zauważyłem ciekawe zachowanie, choć jest oczekiwane, ale nie mogłem znaleźć na to żadnej dokumentacji:
W przypadku Tomcat musisz zdefiniować fabrykę Tomcat (org.apache.tomcat.jdbc.pool.DataSourceFactory lub inne fabryki Tomcat), w przeciwnym razie będzie działać jako Common DBCP.
Istnieją różnice między wartościami domyślnymi Common DBCP i Tomcat DBCP, szczególnie testOnBorrow (true we wspólnym DBCP, ale false w Tomcat DBCP).