Rapide, simple, fiable. HikariCP est un pool de connexions JDBC prêt pour la production « sans surcharge ». Avec environ 165 Ko, la bibliothèque est très légère. Découvrez comment nous procédons ici.
"La simplicité est la condition préalable à la fiabilité."
- Dr Edsger Dijkstra
Important
Afin d'éviter une situation rare où le pool passe à zéro et ne récupère pas, il est nécessaire de configurer TCP keepalive . Certains pilotes JDBC le prennent en charge via des propriétés, par exemple tcpKeepAlive=true
sur PostgreSQL, mais dans tous les cas, cela peut également être configuré au niveau du système d'exploitation. Voir Configuration du système d'exploitation TCP Keepalive et/ou TCP keepalive pour une meilleure expérience PostgreSQL.
Artefact maven Java 11+ :
< dependency >
< groupId >com.zaxxer</ groupId >
< artifactId >HikariCP</ artifactId >
< version >6.2.1</ version >
</ dependency >
Artefact Java 8 maven ( mode maintenance ) :
< dependency >
< groupId >com.zaxxer</ groupId >
< artifactId >HikariCP</ artifactId >
< version >4.0.3</ version >
</ dependency >
Artefact Java 7 maven ( mode maintenance ) :
< dependency >
< groupId >com.zaxxer</ groupId >
< artifactId >HikariCP-java7</ artifactId >
< version >2.4.13</ version >
</ dependency >
Artefact Java 6 maven ( mode maintenance ) :
< dependency >
< groupId >com.zaxxer</ groupId >
< artifactId >HikariCP-java6</ artifactId >
< version >2.3.13</ version >
</ dependency >
Ou téléchargez à partir d'ici.
Des microbenchmarks ont été créés pour isoler et mesurer les frais généraux des pools à l'aide du cadre de microbenchmark JMH. Vous pouvez consulter le projet de référence HikariCP pour plus de détails et consulter/exécuter les tests vous-même.
DataSource.getConnection()
/ Connection.close()
.Connection.prepareStatement()
, Statement.execute()
, Statement.close()
.Analyse de HikariCP v2.6, par rapport à d'autres pools, par rapport à une charge unique de « demande de pointe ».
L'environnement du client imposait un coût élevé d'acquisition de nouvelles connexions et une exigence d'un pool de taille dynamique, mais néanmoins un besoin de réactivité face aux pics de demandes. Apprenez-en davantage sur la gestion de la demande en cas de pic ici.
AKA "Ce que vous ne saviez probablement pas sur le dimensionnement du pool de connexions" . Regardez une vidéo du groupe Oracle Real-world Performance et découvrez pourquoi les connexions aux bases de données n'ont pas besoin d'être aussi nombreuses qu'elles le sont souvent. En fait, un trop grand nombre de connexions a un impact négatif clair et démontrable sur les performances ; une différence de 50x dans le cas de la démonstration Oracle. Lisez la suite pour le découvrir.
Nous aimerions remercier les gars de WIX pour l'article non sollicité et approfondi sur HikariCP sur leur blog d'ingénierie. Jetez un œil si vous avez le temps.
Lisez notre intéressant défi de pool « Base de données en panne ».
Les logiciels open source comme HikariCP, comme tout produit, sont en concurrence sur le marché libre. Nous comprenons. Nous comprenons que les progrès des produits, une fois rendus publics, sont souvent récupérés. Et nous comprenons que les idées peuvent surgir de l’air du temps ; simultanément et indépendamment. Mais la chronologie de l'innovation, en particulier dans les projets open source, est également claire et nous souhaitons que nos utilisateurs comprennent la direction du flux d'innovation dans notre espace. Il pourrait être démoralisant de voir le résultat de centaines d’heures de réflexion et de recherche récupéré si facilement, et c’est peut-être inhérent au libre marché, mais nous ne sommes pas démoralisés. Nous sommes motivés ; pour creuser l'écart.
HikariCP est livré avec des valeurs par défaut saines qui fonctionnent bien dans la plupart des déploiements sans ajustement supplémentaire. Chaque propriété est facultative, à l'exception des "essentiels" indiqués ci-dessous.
? HikariCP utilise les millisecondes pour toutes les valeurs temporelles.
HikariCP s'appuie sur des minuteries précises pour ses performances et sa fiabilité. Il est impératif que votre serveur soit synchronisé avec une source de temps telle qu'un serveur NTP. Surtout si votre serveur s'exécute sur une machine virtuelle. Pourquoi? En savoir plus ici. Ne comptez pas sur les paramètres de l'hyperviseur pour « synchroniser » l'horloge de la machine virtuelle. Configurez la synchronisation de la source de temps à l'intérieur de la machine virtuelle. Si vous demandez de l'aide sur un problème qui s'avère être dû à un manque de synchronisation de l'heure, vous serez publiquement nargué sur Twitter.
? dataSourceClassName
Il s'agit du nom de la classe DataSource
fournie par le pilote JDBC. Consultez la documentation de votre pilote JDBC spécifique pour obtenir ce nom de classe, ou consultez le tableau ci-dessous. Remarque Les sources de données XA ne sont pas prises en charge. XA nécessite un véritable gestionnaire de transactions comme bitronix. Notez que vous n'avez pas besoin de cette propriété si vous utilisez jdbcUrl
pour la configuration du pilote JDBC "à l'ancienne" basée sur DriverManager. Par défaut : aucun
- ou -
? jdbcUrl
Cette propriété indique à HikariCP d'utiliser la configuration « basée sur DriverManager ». Nous pensons que la configuration basée sur DataSource (ci-dessus) est supérieure pour diverses raisons (voir ci-dessous), mais pour de nombreux déploiements, il y a peu de différence significative. Lorsque vous utilisez cette propriété avec des "anciens" pilotes, vous devrez peut-être également définir la propriété driverClassName
, mais essayez-la d'abord sans. Notez que si cette propriété est utilisée, vous pouvez toujours utiliser les propriétés DataSource pour configurer votre pilote et est en fait recommandée plutôt que les paramètres du pilote spécifiés dans l'URL elle-même. Par défaut : aucun
? username
Cette propriété définit le nom d'utilisateur d'authentification par défaut utilisé lors de l'obtention de connexions à partir du pilote sous-jacent. Notez que pour les DataSources, cela fonctionne de manière très déterministe en appelant DataSource.getConnection(*username*, password)
sur le DataSource sous-jacent. Toutefois, pour les configurations basées sur un pilote, chaque pilote est différent. Dans le cas d'un pilote basé sur un pilote, HikariCP utilisera cette propriété username
pour définir une propriété user
dans les Properties
transmises à l'appel DriverManager.getConnection(jdbcUrl, props)
du pilote. Si ce n'est pas ce dont vous avez besoin, ignorez complètement cette méthode et appelez addDataSourceProperty("username", ...)
, par exemple. Par défaut : aucun
? password
Cette propriété définit le mot de passe d'authentification par défaut utilisé lors de l'obtention de connexions à partir du pilote sous-jacent. Notez que pour les DataSources, cela fonctionne de manière très déterministe en appelant DataSource.getConnection(username, *password*)
sur le DataSource sous-jacent. Toutefois, pour les configurations basées sur un pilote, chaque pilote est différent. Dans le cas d'un pilote basé sur un pilote, HikariCP utilisera cette propriété password
pour définir une propriété password
dans les Properties
transmises à l'appel DriverManager.getConnection(jdbcUrl, props)
du pilote. Si ce n'est pas ce dont vous avez besoin, ignorez complètement cette méthode et appelez addDataSourceProperty("pass", ...)
, par exemple. Par défaut : aucun
✅ autoCommit
Cette propriété contrôle le comportement de validation automatique par défaut des connexions renvoyées par le pool. C'est une valeur booléenne. Par défaut : vrai
⏳ connectionTimeout
Cette propriété contrôle le nombre maximum de millisecondes pendant lesquelles un client (c'est-à-dire vous) attendra une connexion depuis le pool. Si ce délai est dépassé sans qu'une connexion ne soit disponible, une exception SQLException sera levée. Le délai d’expiration de connexion le plus bas acceptable est de 250 ms. Par défaut : 30 000 (30 secondes)
⏳ idleTimeout
Cette propriété contrôle la durée maximale pendant laquelle une connexion est autorisée à rester inactive dans le pool. Ce paramètre s'applique uniquement lorsque minimumIdle
est défini comme étant inférieur à maximumPoolSize
. Les connexions inactives ne seront pas supprimées une fois que le pool aura atteint minimumIdle
de connexions inactives. Le fait qu'une connexion soit désactivée ou non est soumis à une variation maximale de +30 secondes et à une variation moyenne de +15 secondes. Une connexion ne sera jamais retirée comme étant inactive avant ce délai. Une valeur de 0 signifie que les connexions inactives ne sont jamais supprimées du pool. La valeur minimale autorisée est de 10 000 ms (10 secondes). Par défaut : 600 000 (10 minutes)
⏳ keepaliveTime
Cette propriété contrôle la fréquence à laquelle HikariCP tentera de maintenir une connexion active, afin d'éviter qu'elle ne soit expirée par la base de données ou l'infrastructure réseau. Cette valeur doit être inférieure à la valeur maxLifetime
. Un « keepalive » ne se produira que sur une connexion inactive. Lorsque le moment est venu d'effectuer un « keepalive » sur une connexion donnée, cette connexion sera supprimée du pool, « pingée », puis renvoyée au pool. Le 'ping' peut être l'un des deux : invocation de la méthode JDBC4 isValid()
ou exécution de connectionTestQuery
. En règle générale, la durée hors du pool doit être mesurée en millisecondes à un chiffre, voire en sous-milliseconde, et ne doit donc avoir que peu ou pas d'impact notable sur les performances. La valeur minimale autorisée est de 30 000 ms (30 secondes), mais une valeur de l'ordre de quelques minutes est la plus souhaitable. Par défaut : 120 000 (2 minutes)
⏳ maxLifetime
Cette propriété contrôle la durée de vie maximale d'une connexion dans le pool. Une connexion en cours d'utilisation ne sera jamais retirée ; ce n'est que lorsqu'elle sera fermée qu'elle sera supprimée. Connexion par connexion, une atténuation négative mineure est appliquée pour éviter une extinction massive dans le pool. Nous vous recommandons fortement de définir cette valeur, et elle doit être plusieurs secondes plus courte que la limite de temps de connexion imposée par toute base de données ou infrastructure. Une valeur de 0 indique qu'il n'y a pas de durée de vie maximale (durée de vie infinie), sous réserve bien sûr du paramètre idleTimeout
. La valeur minimale autorisée est de 30 000 ms (30 secondes). Par défaut : 1 800 000 (30 minutes)
? connectionTestQuery
Si votre pilote prend en charge JDBC4, nous vous recommandons fortement de ne pas définir cette propriété. Ceci concerne les pilotes « hérités » qui ne prennent pas en charge l' Connection.isValid() API
. Il s'agit de la requête qui sera exécutée juste avant qu'une connexion ne vous soit établie depuis le pool pour valider que la connexion à la base de données est toujours active. Encore une fois, essayez d'exécuter le pool sans cette propriété, HikariCP enregistrera une erreur si votre pilote n'est pas conforme à JDBC4 pour vous le faire savoir. Par défaut : aucun
? minimumIdle
Cette propriété contrôle le nombre minimum de connexions inactives que HikariCP tente de maintenir dans le pool. Si les connexions inactives descendent en dessous de cette valeur et que le nombre total de connexions dans le pool est inférieur à maximumPoolSize
, HikariCP fera de son mieux pour ajouter des connexions supplémentaires rapidement et efficacement. Cependant, pour des performances et une réactivité maximales face aux demandes de pointe, nous vous recommandons de ne pas définir cette valeur et d'autoriser plutôt HikariCP à agir comme un pool de connexions de taille fixe . Par défaut : identique à maximumPoolSize
? maximumPoolSize
Cette propriété contrôle la taille maximale que le pool est autorisé à atteindre, y compris les connexions inactives et en cours d'utilisation. Fondamentalement, cette valeur déterminera le nombre maximum de connexions réelles au backend de la base de données. Une valeur raisonnable est mieux déterminée par votre environnement d’exécution. Lorsque le pool atteint cette taille et qu'aucune connexion inactive n'est disponible, les appels à getConnection() seront bloqués pendant jusqu'à connectionTimeout
millisecondes avant d'expirer. Veuillez lire sur la taille de la piscine. Par défaut : 10
? metricRegistry
Cette propriété est uniquement disponible via une configuration programmatique ou un conteneur IoC. Cette propriété vous permet de spécifier une instance d'un Codahale/Dropwizard MetricRegistry
à utiliser par le pool pour enregistrer diverses métriques. Consultez la page wiki Métriques pour plus de détails. Par défaut : aucun
? healthCheckRegistry
Cette propriété est uniquement disponible via une configuration programmatique ou un conteneur IoC. Cette propriété vous permet de spécifier une instance d'un Codahale/Dropwizard HealthCheckRegistry
à utiliser par le pool pour signaler les informations de santé actuelles. Consultez la page wiki Bilans de santé pour plus de détails. Par défaut : aucun
? poolName
Cette propriété représente un nom défini par l'utilisateur pour le pool de connexions et apparaît principalement dans les consoles de journalisation et de gestion JMX pour identifier les pools et les configurations de pool. Par défaut : généré automatiquement
⏳ initializationFailTimeout
Cette propriété contrôle si le pool « échouera rapidement » si le pool ne peut pas être amorcé avec succès avec une connexion initiale. Tout nombre positif est considéré comme le nombre de millisecondes nécessaires pour tenter d'acquérir une connexion initiale ; le fil de candidature sera bloqué pendant cette période. Si une connexion ne peut pas être acquise avant ce délai, une exception sera levée. Ce délai d'attente est appliqué après la période connectionTimeout
. Si la valeur est zéro (0), HikariCP tentera d'obtenir et de valider une connexion. Si une connexion est obtenue, mais échoue à la validation, une exception sera levée et le pool ne démarrera pas. Cependant, si une connexion ne peut pas être obtenue, le pool démarre, mais les efforts ultérieurs pour obtenir une connexion peuvent échouer. Une valeur inférieure à zéro contournera toute tentative de connexion initiale et le pool démarrera immédiatement tout en essayant d'obtenir des connexions en arrière-plan. Par conséquent, les efforts ultérieurs pour obtenir une connexion peuvent échouer. Par défaut : 1
❎ isolateInternalQueries
Cette propriété détermine si HikariCP isole les requêtes de pool internes, telles que le test de connexion active, dans leur propre transaction. Puisqu’il s’agit généralement de requêtes en lecture seule, il est rarement nécessaire de les encapsuler dans leur propre transaction. Cette propriété s'applique uniquement si autoCommit
est désactivé. Par défaut : faux
allowPoolSuspension
Cette propriété contrôle si le pool peut être suspendu et repris via JMX. Ceci est utile pour certains scénarios d’automatisation du basculement. Lorsque le pool est suspendu, les appels à getConnection()
n'expirent pas et seront conservés jusqu'à la reprise du pool. Par défaut : faux
❎ readOnly
Cette propriété contrôle si les connexions obtenues à partir du pool sont en mode lecture seule par défaut. Notez que certaines bases de données ne prennent pas en charge le concept de mode lecture seule, tandis que d'autres fournissent des optimisations de requêtes lorsque la connexion est définie en lecture seule. Que vous ayez ou non besoin de cette propriété dépendra en grande partie de votre application et de votre base de données. Par défaut : faux
❎ registerMbeans
Cette propriété contrôle si les JMX Management Beans (« MBeans ») sont enregistrés ou non. Par défaut : faux
? catalog
Cette propriété définit le catalogue par défaut pour les bases de données prenant en charge le concept de catalogues. Si cette propriété n'est pas spécifiée, le catalogue par défaut défini par le pilote JDBC est utilisé. Par défaut : pilote par défaut
? connectionInitSql
Cette propriété définit une instruction SQL qui sera exécutée après chaque création de nouvelle connexion avant de l'ajouter au pool. Si ce SQL n'est pas valide ou lève une exception, il sera traité comme un échec de connexion et la logique de nouvelle tentative standard sera suivie. Par défaut : aucun
? driverClassName
HikariCP tentera de résoudre un pilote via DriverManager en se basant uniquement sur jdbcUrl
, mais pour certains pilotes plus anciens, le driverClassName
doit également être spécifié. Omettez cette propriété sauf si vous recevez un message d'erreur évident indiquant que le pilote n'a pas été trouvé. Par défaut : aucun
? transactionIsolation
Cette propriété contrôle le niveau d'isolation des transactions par défaut des connexions renvoyées par le pool. Si cette propriété n'est pas spécifiée, le niveau d'isolement des transactions par défaut défini par le pilote JDBC est utilisé. Utilisez cette propriété uniquement si vous avez des exigences d’isolation spécifiques communes à toutes les requêtes. La valeur de cette propriété est le nom de la constante de la classe Connection
telle que TRANSACTION_READ_COMMITTED
, TRANSACTION_REPEATABLE_READ
, etc. Par défaut : pilote par défaut
⏳ validationTimeout
Cette propriété contrôle la durée maximale pendant laquelle l'activité d'une connexion sera testée. Cette valeur doit être inférieure à connectionTimeout
. Le délai d’expiration de validation le plus bas acceptable est de 250 ms. Par défaut : 5 000
leakDetectionThreshold
Cette propriété contrôle la durée pendant laquelle une connexion peut être hors du pool avant qu'un message ne soit enregistré indiquant une éventuelle fuite de connexion. Une valeur de 0 signifie que la détection des fuites est désactivée. La valeur la plus basse acceptable pour activer la détection de fuite est 2000 (2 secondes). Par défaut : 0
➡ dataSource
Cette propriété est uniquement disponible via une configuration programmatique ou un conteneur IoC. Cette propriété vous permet de définir directement l'instance du DataSource
pour qu'elle soit encapsulée par le pool, plutôt que de laisser HikariCP la construire via la réflexion. Cela peut être utile dans certains frameworks d’injection de dépendances. Lorsque cette propriété est spécifiée, la propriété dataSourceClassName
et toutes les propriétés spécifiques à DataSource seront ignorées. Par défaut : aucun
? schema
Cette propriété définit le schéma par défaut pour les bases de données prenant en charge le concept de schémas. Si cette propriété n'est pas spécifiée, le schéma par défaut défini par le pilote JDBC est utilisé. Par défaut : pilote par défaut
➡ threadFactory
Cette propriété est uniquement disponible via une configuration programmatique ou un conteneur IoC. Cette propriété vous permet de définir l'instance de java.util.concurrent.ThreadFactory
qui sera utilisée pour créer tous les threads utilisés par le pool. Il est nécessaire dans certains environnements d'exécution restreints où les threads ne peuvent être créés que via une ThreadFactory
fournie par le conteneur d'application. Par défaut : aucun
➡ scheduledExecutor
Cette propriété est uniquement disponible via une configuration programmatique ou un conteneur IoC. Cette propriété vous permet de définir l'instance de java.util.concurrent.ScheduledExecutorService
qui sera utilisée pour diverses tâches planifiées en interne. Si vous fournissez à HikariCP une instance ScheduledThreadPoolExecutor
, il est recommandé d'utiliser setRemoveOnCancelPolicy(true)
. Par défaut : aucun
➡ exceptionOverride
Cette propriété est uniquement disponible via une configuration programmatique ou un conteneur IoC. Cette propriété vous permet de définir une instance d'une classe, implémentant l'interface com.zaxxer.hikari.SQLExceptionOverride
, qui sera appelée avant qu'une connexion ne soit expulsée du pool en raison de conditions d'exception spécifiques. En règle générale, lorsqu'une SQLException
est levée, les connexions sont expulsées du pool lorsque des SQLStates ou ErrorCodes spécifiques sont présents. La méthode adjudicate()
sera appelée sur l'instance SQLExceptionOverride
, qui peut renvoyer l'un des éléments suivants : Override.CONTINUE_EVICT
. Override.DO_NOT_EVICT
ou Override.MUST_EVICT
. Sauf dans des cas très spécifiques, Override.CONTINUE_EVICT
doit être renvoyé, permettant à la logique d'expulsion/non-expulsion par défaut de s'exécuter. Par défaut : aucun
? exceptionOverrideClassName
Cette propriété vous permet de spécifier le nom d'une classe fournie par l'utilisateur implémentant l'interface com.zaxxer.hikari.SQLExceptionOverride
. Une instance de la classe sera instanciée par le pool pour décider des expulsions de connexion. Voir la propriété exceptionOverride
ci-dessus pour une description complète. Par défaut : aucun
HikariCP a beaucoup de « boutons » à actionner comme vous pouvez le voir ci-dessus, mais comparativement moins que certains autres pools. C'est une philosophie de conception. L’esthétique du design HikariCP est le minimalisme. Conformément à la philosophie de conception simple, c'est mieux ou moins c'est plus , certains axes de configuration sont intentionnellement laissés de côté.
De nombreux pools de connexions, notamment Apache DBCP, Vibur, c3p0 et autres, proposent la mise en cache PreparedStatement
. HikariCP ne le fait pas. Pourquoi?
Au niveau du pool de connexions, PreparedStatements
ne peuvent être mis en cache que par connexion . Si votre application comporte 250 requêtes couramment exécutées et un pool de 20 connexions, vous demandez à votre base de données de conserver 5 000 plans d'exécution de requêtes - et de même, le pool doit mettre en cache autant PreparedStatements
et leur graphique d'objets associé.
La plupart des principaux pilotes JDBC de bases de données disposent déjà d'un cache d'instructions qui peut être configuré, notamment PostgreSQL, Oracle, Derby, MySQL, DB2 et bien d'autres. Les pilotes JDBC occupent une position unique pour exploiter les fonctionnalités spécifiques aux bases de données, et presque toutes les implémentations de mise en cache sont capables de partager des plans d'exécution entre les connexions . Cela signifie qu'au lieu de 5 000 instructions en mémoire et plans d'exécution associés, vos 250 requêtes couramment exécutées aboutissent à exactement 250 plans d'exécution dans la base de données. Les implémentations intelligentes ne conservent même pas les objets PreparedStatement
en mémoire au niveau du pilote, mais attachent simplement de nouvelles instances aux ID de plan existants.
L'utilisation d'un cache d'instructions au niveau de la couche de pooling est un anti-modèle et aura un impact négatif sur les performances de votre application par rapport aux caches fournis par le pilote.
Comme pour la mise en cache des instructions, la plupart des principaux fournisseurs de bases de données prennent en charge la journalisation des instructions via les propriétés de leur propre pilote. Cela inclut Oracle, MySQL, Derby, MSSQL et autres. Certains prennent même en charge la journalisation lente des requêtes. Pour les quelques bases de données qui ne le prennent pas en charge, plusieurs options sont disponibles. Nous avons reçu un rapport indiquant que p6spy fonctionne bien et notons également la disponibilité de log4jdbc et jdbcdslog-exp.
Veuillez lire le Guide de récupération rapide pour plus de détails sur la configuration de votre pilote et de votre système pour une récupération appropriée après le redémarrage de la base de données et les événements de partition réseau.
Vous pouvez utiliser la classe HikariConfig
comme ceci 1 :
HikariConfig config = new HikariConfig ();
config . setJdbcUrl ( "jdbc:mysql://localhost:3306/simpsons" );
config . setUsername ( "bart" );
config . setPassword ( "51mp50n" );
config . addDataSourceProperty ( "cachePrepStmts" , "true" );
config . addDataSourceProperty ( "prepStmtCacheSize" , "250" );
config . addDataSourceProperty ( "prepStmtCacheSqlLimit" , "2048" );
HikariDataSource ds = new HikariDataSource ( config );
1 Exemple spécifique à MySQL, NE COPIEZ PAS VERBATIM.
ou instanciez directement un HikariDataSource
comme ceci :
HikariDataSource ds = new HikariDataSource ();
ds . setJdbcUrl ( "jdbc:mysql://localhost:3306/simpsons" );
ds . setUsername ( "bart" );
ds . setPassword ( "51mp50n" );
...
ou fichier de propriétés basé sur :
// Examines both filesystem and classpath for .properties file
HikariConfig config = new HikariConfig ( "/some/path/hikari.properties" );
HikariDataSource ds = new HikariDataSource ( config );
Exemple de fichier de propriétés :
dataSourceClassName =org.postgresql.ds.PGSimpleDataSource
dataSource.user =test
dataSource.password =test
dataSource.databaseName =mydb
dataSource.portNumber =5432
dataSource.serverName =localhost
ou basé sur java.util.Properties
:
Properties props = new Properties ();
props . setProperty ( "dataSourceClassName" , "org.postgresql.ds.PGSimpleDataSource" );
props . setProperty ( "dataSource.user" , "test" );
props . setProperty ( "dataSource.password" , "test" );
props . setProperty ( "dataSource.databaseName" , "mydb" );
props . put ( "dataSource.logWriter" , new PrintWriter ( System . out ));
HikariConfig config = new HikariConfig ( props );
HikariDataSource ds = new HikariDataSource ( config );
Il existe également une propriété système disponible, hikaricp.configurationFile
, qui peut être utilisée pour spécifier l'emplacement d'un fichier de propriétés. Si vous avez l'intention d'utiliser cette option, construisez une instance HikariConfig
ou HikariDataSource
à l'aide du constructeur par défaut et le fichier de propriétés sera chargé.
Conseils sur les performances MySQL
Nous avons recommandé d'utiliser dataSourceClassName
au lieu de jdbcUrl
, mais l'un ou l'autre est acceptable. Nous le répétons, l’un ou l’autre est acceptable .
Remarque : Utilisateurs de configuration automatique Spring Boot, vous devez utiliser une configuration basée sur jdbcUrl
.
La source de données MySQL est connue pour être en panne en ce qui concerne la prise en charge du délai d'attente du réseau. Utilisez plutôt la configuration jdbcUrl
.
Voici une liste des classes JDBC DataSource pour les bases de données populaires :
Base de données | Conducteur | Classe DataSource |
---|---|---|
Apache Derby | Derby | org.apache.derby.jdbc.ClientDataSource |
Oiseau de feu | oiseau de geai | org.firebirdsql.ds.FBSimpleDataSource |
Clé Google | Clé | com.google.cloud.spanner.jdbc.JdbcDriver |
H2 | H2 | org.h2.jdbcx.JdbcDataSource |
HSQLDB | HSQLDB | org.hsqldb.jdbc.JDBCDataSource |
IBM DB2 | IBM JCC | com.ibm.db2.jcc.DB2SimpleDataSource |
IBM Informix | IBM Informix | com.informix.jdbcx.IfxDataSource |
Serveur MS SQL | Microsoft | com.microsoft.sqlserver.jdbc.SQLServerDataSource |
Connecteur/J | ||
MariaDB | MariaDB | org.mariadb.jdbc.MariaDbDataSource |
Oracle | Oracle | oracle.jdbc.pool.OracleDataSource |
OrientDB | OrientDB | com.orientechnologies.orient.jdbc.OrientDataSource |
PostgreSQL | pgjdbc-ng | com.impossibl.postgres.jdbc.PGDataSource |
PostgreSQL | PostgreSQL | org.postgresql.ds.PGSimpleDataSource |
SAP MaxDB | SÈVE | com.sap.dbtech.jdbc.DriverSapDB |
SQLite | xérial | org.sqlite.SQLiteDataSource |
SyBase | jConnecter | com.sybase.jdbc4.jdbc.SybDataSource |
Remarque Play 2.4 utilise désormais HikariCP par défaut. Un nouveau plugin est apparu pour le framework Play ; jouer-hikaricp. Si vous utilisez l'excellent framework Play, votre application mérite HikariCP. Merci à l'équipe Edulify !
Un nouveau wrapper Clojure a été créé par tomekw et peut être trouvé ici.
Un nouveau wrapper JRuby a été créé par tomekw et peut être trouvé ici.
Groupe de discussion Google HikariCP ici, FAQ croissante.
N'oubliez pas le Wiki pour des informations complémentaires telles que :
⇒ Java 8+ (les artefacts Java 6/7 sont en mode maintenance)
⇒ bibliothèque slf4j
Les projets performants ne peuvent jamais avoir trop d’outils ! Nous tenons à remercier les entreprises suivantes :
Merci à ej-technologies pour leur excellent profileur tout-en-un, JProfiler.
YourKit prend en charge les projets open source avec son profileur Java complet. Cliquez sur le logo YourKit ci-dessous pour en savoir plus.
Veuillez effectuer des modifications et soumettre des demandes d'extraction depuis la branche dev
au lieu de master
. Veuillez configurer votre éditeur pour qu'il utilise des espaces au lieu de tabulations et respectez le style apparent du code que vous modifiez. La branche dev
est toujours plus "actuelle" que la master
si vous cherchez à vivre à la limite.