Options de mise en commun des connexions avec JDBC: DBCP vs C3P0
Quelle est la meilleure bibliothèque de regroupement de connexions disponible pour Java/JDBC?
J'envisage les 2 principaux candidats (free/open-source):
- Apache DBCP - http://commons.Apache.org/dbcp/
- C3P0 - http://sourceforge.net/projects/c3p0
J'ai beaucoup lu à leur sujet dans des blogs et d'autres forums, mais je n'ai pas pu prendre de décision.
Existe-t-il des alternatives pertinentes à ces deux-là?
Le DBCP est obsolète et n’est pas de qualité de production. Il y a quelque temps, nous avons effectué une analyse interne des deux systèmes, créant un appareil de test générant une charge et une concurrence sur ces deux systèmes afin d'évaluer leur pertinence dans des conditions réelles.
Le DBCP générait systématiquement des exceptions dans notre application test et s'efforçait d'atteindre des niveaux de performance que C3P0 était plus que capable de gérer sans aucune exception.
C3P0 a également géré de manière robuste les déconnexions de base de données et les reconnexions transparentes lors de la reprise, alors que DBCP ne récupérait jamais les connexions si la liaison était retirée en dessous. Pire encore, DBCP renvoyait des objets Connection à l’application pour laquelle le transport sous-jacent avait été interrompu.
Depuis lors, nous avons utilisé C3P0 dans 4 grandes applications Web grand public et nous n’avons jamais regardé en arrière.
UPDATE: Il s'avère qu'après avoir passé de nombreuses années sur une étagère, les habitants d'Apache Commons ont mis le DBCP hors de veille et qu'il s'agit à nouveau d'un projet activement développé. Ainsi, mon message original peut être obsolète.
Cela étant dit, je n'ai pas encore expérimenté les performances de cette nouvelle bibliothèque mise à niveau, ni entendu parler de sa présence de facto dans aucun framework d'applications récent.
Je vous invite à essayer BoneCP - qui est gratuit, à code source ouvert et plus rapide que les solutions de rechange disponibles (voir la section consacrée aux points de repère).
Disclaimer: je suis l'auteur donc vous pourriez dire que je suis partial :-)
MISE À JOUR: En mars 2010, la vitesse du nouveau pool Apache DBCP ("Tomcat jdbc") réécritait toujours de 35%. Voir le lien de référence dynamique dans la section de référence.
Mise à jour n ° 2: (décembre 2013) Après 4 ans au sommet, il y a maintenant un concurrent beaucoup plus rapide: https://github.com/brettwooldridge/HikariCP
Mise à jour n ° 3: (sept '14) Veuillez considérer BoneCP comme obsolète à ce stade, recommandez de passer à HikariCP .
Mise à jour n ° 4: (avril '15) - Je ne suis plus propriétaire du domaine jolbox.com, mais le nouveau propriétaire a conservé l'ancien contenu, alors méfiez-vous.
J'avais des problèmes avec DBCP lorsque les connexions ont expiré, j'ai donc testé c3p0. J'allais le mettre en production, mais j'ai commencé les tests de performances. J'ai trouvé que c3p0 effectué terriblement. Je ne pouvais pas le configurer pour bien performer du tout. Je l'ai trouvé deux fois plus lent que DBCP.
J'ai ensuite essayé le pool de connexion Tomcat .
Cela a été deux fois plus rapide que c3p0 et a corrigé d’autres problèmes que je rencontrais avec DBCP. J'ai passé beaucoup de temps à enquêter et à tester les 3 piscines. Si vous déployez sur Tomcat, je vous conseille d'utiliser le nouveau pool JDBC de Tomcat.
Pour le problème de reconnexion automatique avec DBCP, est-ce que quelqu'un a essayé d'utiliser les 2 paramètres de configuration suivants?
validationQuery="Some Query"
testOnBorrow=true
Nous utilisons DBCP depuis quelques années maintenant. Il est stable, survit au redémarrage du serveur de base de données. Il suffit de le configurer correctement. Cela nécessite seulement quelques paramètres à spécifier, alors ne soyez pas paresseux. Voici un extrait de notre code de production système qui répertorie les paramètres que nous avons explicitement définis pour le faire fonctionner:
DriverAdapterCPDS driverAdapterCPDS = new DriverAdapterCPDS();
driverAdapterCPDS.setUrl(dataSourceProperties.getProperty("url"));
driverAdapterCPDS.setUser(dataSourceProperties.getProperty("username"));
driverAdapterCPDS.setPassword(dataSourceProperties.getProperty("password"));
driverAdapterCPDS.setDriver(dataSourceProperties.getProperty("driverClass"));
driverAdapterCPDS.setMaxActive(Integer.valueOf(dataSourceProperties.getProperty("maxActive")));
driverAdapterCPDS.setMaxIdle(Integer.valueOf(dataSourceProperties.getProperty("maxIdle")));
driverAdapterCPDS.setPoolPreparedStatements(Boolean.valueOf(dataSourceProperties.getProperty("poolPreparedStatements")));
SharedPoolDataSource poolDataSource = new SharedPoolDataSource();
poolDataSource.setConnectionPoolDataSource(driverAdapterCPDS);
poolDataSource.setMaxWait(Integer.valueOf(dataSourceProperties.getProperty("maxWait")));
poolDataSource.setDefaultTransactionIsolation(Integer.valueOf(dataSourceProperties.getProperty("defaultTransactionIsolation")));
poolDataSource.setDefaultReadOnly(Boolean.valueOf(dataSourceProperties.getProperty("defaultReadOnly")));
poolDataSource.setTestOnBorrow(Boolean.valueOf(dataSourceProperties.getProperty("testOnBorrow")));
poolDataSource.setValidationQuery("SELECT 0");
Voici quelques articles qui montrent que DBCP a des performances nettement supérieures à C3PO ou à Proxool. De plus, selon ma propre expérience, c3p0 possède certaines fonctionnalités intéressantes, comme le regroupement des instructions préparées, et est plus configurable que DBCP, mais DBCP est nettement plus rapide dans tous les environnements dans lesquels je l'ai utilisé.
Différence entre dbcp et c3p0? Absolument rien! (Un blog de développeurs Sakai) http://blogs.nyu.edu/blogs/nrm216/sakaidelic/2007/12/difference_between_dbcp_and_c3.html
Voir également les articles similaires à l'article de JavaTech "Bilan du pool de connexions" dans les commentaires sur l'article de blog.
Malheureusement, ils sont tous obsolètes. DBCP a été mis à jour un peu récemment, les deux autres ont entre 2 et 3 ans et contiennent de nombreux bogues remarquables.
Dbcp est prêt pour la production s'il est configuré correctement.
Il est par exemple utilisé sur un site marchand de 350000 visiteurs/jour et avec des pools de 200 connexions.
Il gère très bien les délais si vous le configurez correctement.
La version 2 est en cours d’exécution et présente un contexte qui la rend fiable depuis que de nombreux problèmes de production ont été résolus.
Nous l'utilisons pour notre solution de serveur de traitement par lots et des centaines de lots ont été exécutés. Ils fonctionnent sur des millions de lignes de base de données.
Les tests de performances effectués par le pool jdbc Tomcat montrent que ses performances sont meilleures que celles de cp30.
Une autre alternative, Proxool, est mentionnée dans cet article .
Vous pourrez peut-être comprendre pourquoi Hibernate regroupe c3p0 pour son implémentation de pool de connexions par défaut
Je viens de finir de perdre un jour et demi avec DBCP. Bien que j'utilise la dernière version de DBCP, j'ai rencontré exactement les mêmes problèmes que j pimmel did. Je ne recommanderais pas du tout DBCP, en particulier il est capable de jeter des connexions hors du pool lorsque la base de données disparaît, de son incapacité à se reconnecter lorsque la base de données revient et de son incapacité à ajouter de manière dynamique des objets de connexion une socket post JDBCconnect I/O lue)
Je passe maintenant à C3P0. Je l'ai utilisé dans des projets précédents et cela a fonctionné et exécuté comme un charme.
c3p0 est bon lorsque nous utilisons des projets de multithreading. Dans nos projets, nous utilisions simultanément plusieurs exécutions de threads à l'aide de DBCP, puis nous expirions le délai de connexion si nous utilisions davantage d'exécutions de threads. Nous sommes donc allés avec la configuration c3p0.
Une bonne alternative facile à utiliser est DBPool .
"Un utilitaire de regroupement de connexions de base de données basé sur Java, prenant en charge l’expiration temporelle, la mise en cache des instructions, la validation de la connexion et la configuration facile à l’aide d’un gestionnaire de pool."
Pour implémenter le C3P0 de la meilleure façon alors cochez cette réponse
C3P0:
Pour les applications d'entreprise, C3P0 est la meilleure approche. C3P0 est une bibliothèque facile à utiliser pour augmenter les pilotes JDBC traditionnels (basés sur DriverManager) avec des sources de données pouvant être reliées JNDI, y compris des sources de données qui implémentent la mise en pool de connexions et d'instructions, comme décrit dans les spécifications jdbc3 et l'extension jdbc2 std .C3P0 a également géré de manière robuste les déconnexions de base de données et les reconnexions transparentes lors de la reprise, alors que DBCP ne récupérait jamais les connexions si la liaison était retirée.
C’est la raison pour laquelle c3p0 et d’autres pools de connexions ont également préparé des caches d’instruction, ce qui permet au code de l’application d’éviter de traiter tout cela. Les instructions sont généralement conservées dans un pool LRU limité. Par conséquent, les instructions courantes réutilisent une instance de PreparedStatement.
Pire encore, DBCP renvoyait des objets Connection à l’application pour laquelle le transport sous-jacent s’était rompu . Un cas d’utilisation courant de c3p0 consiste à remplacer le pooling de connexion DBCP standard inclus avec Apache Tomcat. Souvent, un programmeur se trouve dans une situation où les connexions ne sont pas correctement recyclées dans le pool de connexions DBCP et où c3p0 constitue un remplacement précieux dans ce cas.
Dans les mises à jour actuelles, C3P0 a quelques fonctionnalités brillantes. ceux-ci sont donnés ci-dessous:
ComboPooledDataSource dataSource = new ComboPooledDataSource();
dataSource.setMinPoolSize();
dataSource.setMaxPoolSize();
dataSource.setMaxIdleTime();
dataSource.setMaxStatements();
dataSource.setMaxStatementsPerConnection();
dataSource.setMaxIdleTimeExcessConnections();
Ici, max et min poolsize définissent les limites de la connexion, c'est-à-dire les connexions minimale et maximale de cette application. MaxIdleTime() définir quand il libérera la connexion inactive.
DBCP:
Cette approche est également bonne, mais présente des inconvénients tels que le délai de connexion et la réalisation de la connexion . C3P0 est bon lorsque nous utilisons des projets multithreading. Dans nos projets, nous utilisions simultanément plusieurs exécutions de threads à l'aide de DBCP, puis nous expirions le délai de connexion si nous utilisions davantage d'exécutions de threads. Nous sommes donc allés avec la configuration c3p0 . Je ne recommanderais pas du tout DBCP, en particulier il est capable de jeter des connexions hors du pool lorsque la base de données disparaît, de son incapacité à se reconnecter lorsque la base de données revient et de son incapacité à ajouter de manière dynamique une connexion. les objets dans le pool (il se bloque pour toujours sur une lecture post-socket JDBCconnect I/O)
Merci :)
ma recommandation est
hikari> druide> UCP> c3p0> DBCP
Il est basé sur ce que j'ai testé - 20190202, dans mon environnement de test local (4 Go mac/mysql dans docker/pool minSize = 1, maxSize = 8), hikari peut servir 1024 threads x 1024 fois pour obtenir des connexions, temps moyen pour chaque thread Pour terminer, il faut 1 ou 2 millions de secondes, alors que c3p0 ne peut servir que 256 threads x 1024 fois et que le temps moyen pour chaque thread est déjà de 21 millions de secondes. (512 threads ont échoué).