c3p0
1.0.0
c3p0 est une bibliothèque de pooling de connexions JDBC mature et hautement concurrente, avec prise en charge de la mise en cache et de la réutilisation des objets PreparedStatement .
c3p0 est disponible en tant que dépendance gérée sur Maven Central, [groupId: com.mchange, artifactId: c3p0] Pour les versions disponibles, regardez ici.
Veuillez consulter la documentation pour en savoir plus.
À partir de l' instantané de développement actuel, voici le dernier CHANGELOG.
Veuillez adresser vos commentaires et questions à l'auteur de la bibliothèque.
Cependant, gardez à l’esprit qu’il est un correspondant épouvantable et fondamentalement un connard.
Malgré cela, vos commentaires sont très appréciés. Les demandes de tirage sont acceptées avec gratitude. Vous pouvez également ouvrir des tickets.
Merci de votre intérêt pour c3p0. J'espère que cela vous sera utile !
Pour l'instant (v0.10.1), c3p0 est construit sous une machine virtuelle Java 11, ciblant les fichiers de classe JDK 7 pour une compatibilité continue avec les applications héritées.
Afin de me rappeler de passer à Java 11, la build échouera avec une exception si elle détecte une version inattendue.
Vous pouvez commenter cette exigence depuis build.sc si vous le souhaitez. C'est la ligne qui ressemble à
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 s'appuie sur l'excellente mill à outils de construction.
Installer mill . Ensuite, dans ce répertoire du référentiel, exécutez
$ mill jar
Vous trouverez le brut sous forme de bibliothèque out/jar.dest/out.jar .
Si vous gérez un référentiel ivy local, vous pouvez personnaliser publishVersion dans build.sc , puis exécuter
$ mill publishLocal
Pour construire la documentation
$ mill doc.docroot
Vous pouvez ensuite ouvrir dans votre navigateur out/doc/docroot.dest/index.html
Par défaut, les tests s'attendent à trouver une base de données à l' jdbc:postgresql://localhost:5432/c3p0 . Comme vous pouvez le voir, je teste généralement sur une base de données Postgres locale. Vous pouvez modifier cela dans la fonction forkArgs de build.sc .
Les tests de c3p0 sont, euh, embarrassants et informels. Il existe une suite de tests Junit, mais elle couvre une très petite fraction des fonctionnalités de c3p0. Pour exécuter ça, c'est juste
$ mill test.test
La plupart du temps, c3p0 est testé en exécutant quelques applications de test et en variant la configuration ad hoc pour voir comment les choses fonctionnent.
Si vous pensez que c3p0 pourrait/devrait être testé de manière plus professionnelle et automatique, moi aussi ! J'adorerais une pull request.
build.sc contient de nombreuses applications de test, mais les plus importantes sont
$ mill test.c3p0Benchmark
Il s’agit du test de premier recours le plus basique et le plus courant du c3p0. Il exécute et chronomètre un tas d'opérations c3p0 différentes, et soumet la bibliothèque à un très bon exercice.
$ mill test.c3p0Load
Celui-ci met c3p0 sous la charge de 100 threads effectuant chacun 1 000 opérations de base de données, puis se termine.
$ mill test.c3p0PSLoad
Celui-ci met c3p0 sous la charge d'un 100 thread effectuant indéfiniment des opérations de base de données. Il utilise PreparedStatement pour ses opérations de base de données, c'est donc un bon moyen d'exercer le cache d'instructions.
Vous pouvez observer (la plupart) la configuration de votre DataSource c3p0 lorsque vous testez, car c3p0 l'enregistre dans INFO lors de la première tentative de vérification Connection . Lors des tests, vérifiez que vous travaillez avec la configuration attendue !
Les tests sont configurés par des arguments de ligne de commande et par un fichier c3p0.properties . Pour jouer avec différentes configurations, éditez test/resources-local/c3p0.properties . Vérifiez également la méthode forkArgs() dans build.sc
Parfois, on a envie de mettre la bibliothèque à l'épreuve avec une configuration pathologique. Une configuration pathologique de base est définie dans test/resources-local-rough/c3p0.properties .
Pour donner cet effet, éditez temporairement build.sc :
override def runClasspath : T [ Seq [ PathRef ]] = T {
super .runClasspath() ++ localResources()
// super.runClasspath() ++ localResourcesRough()
}super.runClasspath() ++ localResources()super.runClasspath() ++ localResourcesRough() Ensuite, bien sûr, vous pouvez modifier test/resources-local-rough/c3p0.properties .
Souvent, vous souhaiterez concentrer la journalisation sur une classe ou une fonctionnalité que vous testez. Par défaut, les tests c3p0 sont configurés pour utiliser java.util.logging. , et être configuré par le fichier test/conf-logging/logging.properties .
Bien sûr, vous pouvez modifier la configuration (dans c3p0.properties ) pour utiliser une autre bibliothèque de journalisation si vous le souhaitez, mais vous devrez peut-être modifier la version pour intégrer des bibliothèques de journalisation tierces et configurer ces bibliothèques à leur manière.
Étant donné que c3p0 est actuellement construit sous Java 11, mais que c3p0-loom nécessite Java 21, c3p0 loom est un projet distinct.
Il s'agit simplement d'un projet d'usine parallèle. Les instructions ci-dessus s'appliquent (sauf que c3p0-loom n'a pas de documentation indépendante à construire).
c3p0 est sous licence LGPL v.2.1 ou EPL v.1.0, à votre choix. Vous pouvez également choisir d'obtenir une licence c3p0 sous n'importe quelle version de LGPL supérieure à la v.2.1.
Remarque : c3p0 a eu une bonne expérience en matière de signalement d'une vulnérabilité de sécurité via le Central Security Project de Sonatype. Si vous trouvez un problème de sécurité c3p0, envisagez de le signaler via https://hackerone.com/central-security-project
