c3p0
1.0.0
c3p0 ist eine ausgereifte, hochgradig gleichzeitige JDBC-Verbindungspooling-Bibliothek mit Unterstützung für das Caching und die Wiederverwendung von PreparedStatement Objekten.
c3p0 ist als verwaltete Abhängigkeit von Maven Central verfügbar, [groupId: com.mchange, artifactId: c3p0] Verfügbare Versionen finden Sie hier.
Weitere Informationen finden Sie in der Dokumentation.
Aus dem aktuellen Entwicklungs-Snapshot ist hier das neueste CHANGELOG.
Bitte richten Sie Kommentare und Fragen an den Bibliotheksautor.
Bedenken Sie jedoch bitte, dass er ein miserabler Korrespondent und im Grunde ein Arschloch ist.
Dennoch freuen wir uns sehr über Ihr Feedback. Pull-Requests werden dankbar angenommen. Sie können auch Probleme eröffnen.
Vielen Dank für Ihr Interesse an c3p0. Ich hoffe, dass Sie es nützlich finden!
Derzeit (v0.10.1) wird c3p0 unter einer Java 11-VM erstellt und zielt auf JDK 7-Klassendateien ab, um weiterhin Kompatibilität mit älteren Apps zu gewährleisten.
Um mich daran zu erinnern, auf Java 11 umzusteigen, schlägt der Build mit einer Ausnahme fehl, wenn er eine unerwartete Version erkennt.
Wenn Sie möchten, können Sie diese Anforderung in build.sc auskommentieren. Es ist die Linie, die aussieht
require( sys.props( " java.runtime.version " ).startsWith( " 11 " ), s " Bad build JVM: ${sys.props( " java.runtime.version " )} -- We currently expect to build under Java 11. (We generate Java $JvmCompatVersion compatible source files.) " ) c3p0 setzt auf das hervorragende Build-Tool mill .
mill installieren. Führen Sie dann innerhalb dieses Repository-Verzeichnisses den Befehl aus
$ mill jar
Sie finden das Raw als Bibliothek out/jar.dest/out.jar .
Wenn Sie ein lokales Ivy-Repository verwalten, können Sie publishVersion in build.sc anpassen und dann ausführen
$ mill publishLocal
Um die Dokumentation zu erstellen
$ mill doc.docroot
Anschließend können Sie in Ihrem Browser out/doc/docroot.dest/index.html öffnen
Standardmäßig erwarten die Tests, eine Datenbank unter jdbc:postgresql://localhost:5432/c3p0 zu finden. Wie Sie sehen, teste ich normalerweise anhand einer lokalen Postgres-Datenbank. Sie können dies in der Funktion forkArgs von build.sc ändern.
Die Tests von c3p0 sind, ähm, peinlich informell. Es gibt eine Junit-Testsuite, die jedoch nur einen sehr kleinen Teil der c3p0-Funktionalität abdeckt. Um das auszuführen, ist es einfach
$ mill test.test
Meistens wird c3p0 getestet, indem einige Testanwendungen ausgeführt und die Konfiguration ad hoc variiert werden, um zu sehen, wie die Dinge funktionieren.
Wenn Sie der Meinung sind, dass c3p0 professioneller und automatischer getestet werden könnte/sollte, dann bin ich auch der Meinung! Ich würde mich über eine Pull-Anfrage freuen.
build.sc enthält viele Testanwendungen, aber die wichtigsten sind
$ mill test.c3p0Benchmark
Dies ist der einfachste und gebräuchlichste c3p0-Test der ersten Wahl. Es durchläuft eine Reihe unterschiedlicher c3p0-Operationen und stellt deren Zeitmessung sicher, wodurch die Bibliothek ziemlich gut beansprucht wird
$ mill test.c3p0Load
Dieser setzt c3p0 unter die Last von 100 Threads, die jeweils 1000 Datenbankoperationen ausführen, und wird dann beendet.
$ mill test.c3p0PSLoad
Dieser setzt c3p0 unter die Last eines 100 Threads, der Datenbankoperationen auf unbestimmte Zeit durchführt. Es verwendet PreparedStatement für seine Datenbankoperationen und ist somit eine gute Möglichkeit, den Anweisungscache zu nutzen.
Sie können (den größten Teil) der Konfiguration Ihrer c3p0- DataSource beim Testen beobachten, da c3p0 sie beim ersten Connection -Auscheckversuch unter INFO protokolliert. Stellen Sie beim Testen sicher, dass Sie mit der erwarteten Konfiguration arbeiten!
Tests werden durch Befehlszeilenargumente und eine c3p0.properties Datei konfiguriert. Um mit verschiedenen Konfigurationen zu spielen, bearbeiten Sie test/resources-local/c3p0.properties . Überprüfen Sie auch die Methode forkArgs() in build.sc
Manchmal möchte man die Bibliothek mit pathologischer Konfiguration auf Herz und Nieren prüfen. Eine pathologische Grundkonfiguration ist in test/resources-local-rough/c3p0.properties definiert.
Um diesen Effekt zu erzielen, bearbeiten Sie build.sc vorübergehend:
override def runClasspath : T [ Seq [ PathRef ]] = T {
super .runClasspath() ++ localResources()
// super.runClasspath() ++ localResourcesRough()
}super.runClasspath() ++ localResources() aussuper.runClasspath() ++ localResourcesRough() Dann können Sie natürlich test/resources-local-rough/c3p0.properties bearbeiten.
Häufig möchten Sie die Protokollierung auf eine Klasse oder Funktion konzentrieren, die Sie testen. Standardmäßig sind c3p0-Tests für die Verwendung java.util.logging. und durch die Datei test/conf-logging/logging.properties konfiguriert werden.
Natürlich können Sie die Konfiguration (in c3p0.properties ) ändern, um eine andere Protokollierungsbibliothek zu verwenden, wenn Sie möchten, aber Sie müssen möglicherweise den Build ändern, um Protokollierungsbibliotheken von Drittanbietern einzubeziehen, und diese Bibliotheken auf ihre eigene Weise konfigurieren.
Da c3p0 derzeit unter Java 11 erstellt wird, c3p0-loom jedoch Java 21 erfordert, ist c3p0 loom ein separates Projekt.
Es handelt sich lediglich um ein paralleles Mühlenprojekt. Es gelten die obigen Anweisungen (mit der Ausnahme, dass c3p0-loom keine unabhängige Dokumentation zum Erstellen hat).
c3p0 ist nach Ihrer Wahl unter LGPL v.2.1 oder EPL v.1.0 lizenziert. Sie können sich auch dafür entscheiden, c3p0 unter einer beliebigen LGPL-Version höher als v.2.1 zu lizenzieren.
Hinweis: c3p0 hat gute Erfahrungen mit der Meldung einer Sicherheitslücke über das Central Security Project von Sonatype gemacht. Wenn Sie ein c3p0-Sicherheitsproblem feststellen, sollten Sie es über https://hackerone.com/central-security-project melden
