tomcat-dbcp vs commons-dbcp

Es scheint, dass zwischen diesen beiden Verbindungspooling-Bibliotheken große Verwirrung herrscht. Was ich wissen möchte ist, welches besser ist (wenn überhaupt)?

Hier sind einige Punkte, die ich ansprechen möchte ... Könnte jemand bitte überprüfen?

1. Tomcat DBCP: Verwendet die Standarddatei tomcat-dbcp.jar, die in Ihrem Verzeichnis tomcat / lib vorhanden ist. Sie nicht commons-dbcp.jar oder commons-pool.jar Bibliotheken in Ihrem Web-inf / lib benötigen. Der DB-Treiber sollte in tomcat / lib abgelegt werden.

2. Tomcat DBCP-Datenquellenklasse ist org.apache.tomcat.dbcp.dbcp.BasicDataSource. Commons DBCP-Datenquellenklasse ist org.apache.commons.dbcp.BasicDataSource.

3. Der einzige Unterschied zwischen diesen beiden kann in diesem Blog gefunden werden . Ich weiß nicht, ob die Informationen korrekt sind oder nicht.

4. In der offiziellen Tomcat-Dokumentation wird deutlich erwähnt, dass die meisten Klassen gerade umbenannt und neu verpackt wurden.

Die Frage ist also: Welches ist zu verwenden und welches ist besser ?

Tomcat DBCP ist nur eine umbenannte Version von Apache Commons DBCP mit einem anderen internen Paketnamenpräfix.

Zur Erstellungszeit ruft Tomcat die Commons-DBCP-Quellen ab (die Version hängt von der Tomcat-Version ab, z. B. verwendet Tomcat 7.0.27 Commons DBCP 1.4), ersetzt den Paketnamen ( org.apache.commons-> org.apache.tomcat.dbcp) und erstellt das Ergebnis alstomcat-dbcp.jar .

Dies geschieht, damit die internen Tomcat-JDBC-Pools niemals mit möglichen Anwendungsverwendungen der Commons-DBCP-Klassen in Konflikt stehen. Dies vermeidet viele potenzielle Probleme beim Laden von Klassen.

Bearbeiten: In den "dbcp" -Paketen geht es um die Verwaltung von Datenquellen. Für die reine Poolimplementierung hängt Commons DBCP vom Commons Pool (Paket org.apache.commons.pool) ab. In Tomcat wird die Implementierung des Pools jedoch durch den eigenen JDBC-Pool (Paket org.apache.tomcat.jdbc.pool) von Tomcat ersetzt .

Es scheint, dass zwischen diesen beiden Verbindungspooling-Bibliotheken große Verwirrung herrscht. Was ich wissen möchte ist, welches besser ist (wenn überhaupt)?

TL / DR: Diese sind gleich, verwenden Sie keine von beiden.

Tomcat-dbcp ist das ursprüngliche Re-Paket des Apache Commons-Pools, das in der Tomcat-Distribution enthalten ist. Um Klassenkonflikte zu vermeiden, wurde das Paket in org.apache.tomcat.dbcp.dbcp umbenannt. *

In Tomcat 7 (ab 7.0.19 im Juli 2011) wurde im Standard-Tomcat-Paket (als Teil von tomcat-jdbc.jar) ein zusätzlicher Verbindungspool als Alternative zur veralteten Apache-Commons-Implementierung mit dem Namen "The Tomcat JDBC Connection Pool" aufgenommen:

https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html

Dieser Artikel behandelt die Unterschiede zwischen den beiden:

http://vigilbose.blogspot.com/2009/03/apache-commons-dbcp-and-tomcat-jdbc.html

Kurze Zusammenfassung, warum der neue Tomcat-Pool besser ist:

• aktiv unterstützt
• viel kleiner, leichter zu verstehen und zu warten (wenn Sie sich die Quelle ansehen möchten)
• unterstützt alle commons-dbcp-Funktionen + fügt super nützliche Funktionen wie "initSQL", "validationInterval", "jdbcInterceptors" und mehr hinzu

Ältere Versionen von Apache Commons DBCP (dh Version 1.2) hatten unter Bedingungen hoher Last einige unangenehme Probleme mit der Thread-Sicherheit, so dass es für diese Art der Verwendung ungeeignet war. Es überrascht mich nicht, dass die Tomcat-Leute es überarbeitet haben, um diese Probleme zu beheben.

Nach meinem Verständnis behebt Commons DBCP 1.4 diese Probleme. Ich kann das nicht persönlich bestätigen, aber es kann die Tomcat-Version überflüssig machen.

Interessanterweise hat SpringSource auch Commons DBCP für die neu gepackte Version von Tomcat (tc-Server) neu geschrieben und behauptet, große Leistungsvorteile daraus zu ziehen. Das haben sie allerdings nicht als Open-Source-Lösung.

Tomcat 7 verwendet weiterhin DBCP. Der Hauptgrund könnte in ihren Tomcat-Dokumenten verborgen sein:

• Der Apache Commons DBCP kann so konfiguriert werden, dass diese abgebrochenen Datenbankverbindungen verfolgt und wiederhergestellt werden. Es kann sie nicht nur wiederherstellen, sondern auch einen Stack-Trace für den Code generieren, der diese Ressourcen geöffnet und nie geschlossen hat.

• Tomcat-JDBC-Pool-Bibliothek, möglicherweise schneller in sehr gleichzeitigen Szenarien, kann jedoch Anweisungen nicht automatisch schließen und freigeben (was ein Entwickler vergessen hat, zu schließen), was bei einigen JDBC-Treibern zu möglichen Speicherverlusten führen kann.

Eines der Probleme mit DBCP-Code ist jedoch das von ihnen verwendete Delegierungsmodell. Derzeit unterstützen die neuesten Versionen JDK1.6 und niedriger. 1.7 zu unterstützen bedeutet, mindestens ein Viertel ihrer Klassen zu ändern, was einer der Gründe war, warum die JDBC-Poolbibliothek ins Leben gerufen wurde.

ANMERKUNG: Nach weiteren Untersuchungen kann der JDBC-Pool Eröffnungsanweisungen schließen, wenn eine Verbindung mit einem StatementFinalizerInterceptor geschlossen wird .

Nur um hier hinzuzufügen: Ich habe ein interessantes Verhalten festgestellt, obwohl es erwartet wird, konnte aber keine Dokumentation dafür finden:

Für Tomcat müssen Sie die Tomcat-Factory ( org.apache.tomcat.jdbc.pool.DataSourceFactoryoder andere Tomcat-Fabriken) definieren, da sie sonst als Common DBCP funktioniert.

Insbesondere gibt es Unterschiede zwischen den Standardwerten von Common DBCP und Tomcat DBCP testOnBorrow( truein Common DBCP, aber falsein Tomcat DBCP).

Hier ist eine Liste der Vorteile der Verwendung des Tomcat JDBC-Pools anstelle von commons-dbcp: http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html