HikariCP é mais rápido. Hi·ka·ri [hi·ka·'lē] ( Origem: Japonês ): luz; raio.Rápido, simples e confiável. HikariCP é um pool de conexões JDBC pronto para produção com "sobrecarga zero". Com aproximadamente 165 KB, a biblioteca é muito leve. Leia sobre como fazemos isso aqui.
"Simplicidade é pré-requisito para confiabilidade."
- Dr.
Importante
Para evitar uma condição rara em que o pool vai a zero e não se recupera é necessário configurar o keepalive do TCP . Alguns drivers JDBC suportam isso por meio de propriedades, por exemplo tcpKeepAlive=true no PostgreSQL, mas em qualquer caso também pode ser configurado no nível do sistema operacional. Consulte Configurando o Keepalive do TCP do SO e/ou Keepalive do TCP para uma melhor experiência do PostgreSQL.
Artefato maven Java 11+ :
< dependency >
< groupId >com.zaxxer</ groupId >
< artifactId >HikariCP</ artifactId >
< version >6.2.1</ version >
</ dependency >Artefato maven Java 8 ( modo de manutenção ):
< dependency >
< groupId >com.zaxxer</ groupId >
< artifactId >HikariCP</ artifactId >
< version >4.0.3</ version >
</ dependency >Artefato maven Java 7 ( modo de manutenção ):
< dependency >
< groupId >com.zaxxer</ groupId >
< artifactId >HikariCP-java7</ artifactId >
< version >2.4.13</ version >
</ dependency >Artefato maven Java 6 ( modo de manutenção ):
< dependency >
< groupId >com.zaxxer</ groupId >
< artifactId >HikariCP-java6</ artifactId >
< version >2.3.13</ version >
</ dependency >Ou baixe aqui.
Microbenchmarks foram criados para isolar e medir a sobrecarga de pools usando a estrutura de microbenchmark JMH. Você pode verificar o projeto de benchmark HikariCP para obter detalhes e revisar/executar os benchmarks você mesmo.
DataSource.getConnection() / Connection.close() .Connection.prepareStatement() , Statement.execute() , Statement.close() .
Análise do HikariCP v2.6, em comparação com outros pools, em relação a uma carga única de “pico de demanda”.
O ambiente do cliente impôs um alto custo de aquisição de novas conexões e uma exigência de um pool de tamanho dinâmico, mas ainda uma necessidade de capacidade de resposta para solicitar picos. Leia sobre o tratamento do pico de demanda aqui.
Também conhecido como "O que você provavelmente não sabia sobre o dimensionamento do pool de conexões" . Assista a um vídeo do grupo Oracle Real-world Performance e saiba por que as conexões com o banco de dados não precisam ser tão numerosas como costumam ser. Na verdade, demasiadas ligações têm um impacto negativo claro e demonstrável no desempenho; uma diferença de 50x no caso da demonstração da Oracle. Continue lendo para descobrir.
Gostaríamos de agradecer ao pessoal do WIX pelo artigo profundo e não solicitado sobre o HikariCP em seu blog de engenharia. Dê uma olhada se tiver tempo.
Leia nosso interessante desafio de pool "Banco de dados desativado".
Software de código aberto como o HikariCP, como qualquer produto, compete no mercado livre. Nós entendemos. Entendemos que os avanços dos produtos, uma vez públicos, são frequentemente cooptados. E entendemos que as ideias podem surgir do zeitgeist; simultaneamente e de forma independente. Mas o cronograma da inovação, especialmente em projetos de código aberto, também é claro e queremos que os nossos utilizadores compreendam a direção do fluxo da inovação no nosso espaço. Poderia ser desmoralizante ver o resultado de centenas de horas de reflexão e investigação cooptadas tão facilmente, e talvez isso seja inerente a um mercado livre, mas não estamos desmoralizados. Estamos motivados; para ampliar a lacuna.
HikariCP vem com padrões sensatos que funcionam bem na maioria das implantações sem ajustes adicionais. Todas as propriedades são opcionais, exceto as "essenciais" marcadas abaixo.
? HikariCP usa milissegundos para todos os valores de tempo.
HikariCP depende de temporizadores precisos para desempenho e confiabilidade. É imperativo que o seu servidor esteja sincronizado com uma fonte de tempo, como um servidor NTP. Principalmente se o seu servidor estiver rodando em uma máquina virtual. Por que? Leia mais aqui. Não confie nas configurações do hipervisor para “sincronizar” o relógio da máquina virtual. Configure a sincronização de origem de tempo dentro da máquina virtual. Se você pedir suporte sobre um problema que acaba sendo causado por falta de sincronização de horário, você será insultado publicamente no Twitter.
? dataSourceClassName
Este é o nome da classe DataSource fornecida pelo driver JDBC. Consulte a documentação do seu driver JDBC específico para obter esse nome de classe ou consulte a tabela abaixo. Nota As fontes de dados XA não são suportadas. XA requer um gerenciador de transações real como o bitronix. Observe que você não precisa dessa propriedade se estiver usando jdbcUrl para configuração de driver JDBC "antiga" baseada em DriverManager. Padrão: nenhum
- ou -
? jdbcUrl
Esta propriedade orienta o HikariCP a usar a configuração "baseada em DriverManager". Acreditamos que a configuração baseada em DataSource (acima) é superior por vários motivos (veja abaixo), mas para muitas implantações há pouca diferença significativa. Ao usar esta propriedade com drivers "antigos", você também pode precisar definir a propriedade driverClassName , mas tente primeiro sem. Observe que se esta propriedade for usada, você ainda poderá usar propriedades DataSource para configurar seu driver e é de fato recomendada em vez de parâmetros de driver especificados na própria URL. Padrão: nenhum
? username
Esta propriedade define o nome de usuário de autenticação padrão usado ao obter conexões do driver subjacente. Observe que para DataSources isso funciona de maneira muito determinística, chamando DataSource.getConnection(*username*, password) no DataSource subjacente. No entanto, para configurações baseadas em driver, cada driver é diferente. No caso de baseado em driver, o HikariCP usará esta propriedade username para definir uma propriedade user nas Properties passadas para a chamada DriverManager.getConnection(jdbcUrl, props) do driver. Se não for isso que você precisa, ignore totalmente este método e chame addDataSourceProperty("username", ...) , por exemplo. Padrão: nenhum
? password
Esta propriedade configura a senha de autenticação padrão usada ao obter conexões do driver subjacente. Observe que para DataSources isso funciona de maneira muito determinística, chamando DataSource.getConnection(username, *password*) no DataSource subjacente. No entanto, para configurações baseadas em driver, cada driver é diferente. No caso de baseado em driver, o HikariCP usará esta propriedade password para definir uma propriedade password nas Properties passadas para a chamada DriverManager.getConnection(jdbcUrl, props) do driver. Se não for isso que você precisa, ignore totalmente este método e chame addDataSourceProperty("pass", ...) , por exemplo. Padrão: nenhum
✅ autoCommit
Esta propriedade controla o comportamento padrão de confirmação automática das conexões retornadas do pool. É um valor booleano. Padrão: verdadeiro
⏳ connectionTimeout
Esta propriedade controla o número máximo de milissegundos que um cliente (você) aguardará por uma conexão do pool. Se esse tempo for excedido sem que uma conexão fique disponível, uma SQLException será lançada. O tempo limite de conexão mais baixo aceitável é 250 ms. Padrão: 30.000 (30 segundos)
⏳ idleTimeout
Essa propriedade controla o tempo máximo que uma conexão pode permanecer inativa no conjunto. Essa configuração se aplica apenas quando minimumIdle é definido como menor que maximumPoolSize . As conexões inativas não serão descontinuadas quando o pool atingir conexões minimumIdle . O fato de uma conexão ser desativada ou não está sujeito a uma variação máxima de +30 segundos e uma variação média de +15 segundos. Uma conexão nunca será desativada como inativa antes desse tempo limite. Um valor 0 significa que as conexões inativas nunca são removidas do conjunto. O valor mínimo permitido é 10000ms (10 segundos). Padrão: 600.000 (10 minutos)
⏳ keepaliveTime
Esta propriedade controla a frequência com que o HikariCP tentará manter uma conexão ativa, para evitar que ela seja expirada pelo banco de dados ou pela infraestrutura de rede. Este valor deve ser menor que o valor maxLifetime . Um "keepalive" ocorrerá apenas em uma conexão inativa. Quando chegar a hora de um "keepalive" em uma determinada conexão, essa conexão será removida do pool, "pingada" e depois retornada ao pool. O 'ping' é um dos seguintes: invocação do método JDBC4 isValid() ou execução do connectionTestQuery . Normalmente, a duração fora do pool deve ser medida em milissegundos de um dígito ou mesmo em menos de milissegundos e, portanto, deve ter pouco ou nenhum impacto perceptível no desempenho. O valor mínimo permitido é 30.000ms (30 segundos), mas um valor na faixa de minutos é o mais desejável. Padrão: 120.000 (2 minutos)
⏳ maxLifetime
Esta propriedade controla o tempo de vida máximo de uma conexão no pool. Uma conexão em uso nunca será descontinuada; somente quando for fechada será removida. Conexão por conexão, uma atenuação negativa menor é aplicada para evitar a extinção em massa no pool. É altamente recomendável definir esse valor, e ele deve ser vários segundos menor que qualquer limite de tempo de conexão imposto por banco de dados ou infraestrutura. Um valor 0 indica que não há tempo de vida máximo (vida útil infinita), sujeito, é claro, à configuração de idleTimeout . O valor mínimo permitido é 30.000ms (30 segundos). Padrão: 1800000 (30 minutos)
? connectionTestQuery
Se o seu driver suportar JDBC4, recomendamos fortemente não configurar esta propriedade. Isto é para drivers "herdados" que não suportam a Connection.isValid() API . Esta é a consulta que será executada imediatamente antes de uma conexão ser fornecida a você a partir do pool para validar se a conexão com o banco de dados ainda está ativa. Novamente, tente executar o pool sem esta propriedade, o HikariCP registrará um erro se o seu driver não for compatível com JDBC4 para avisar você. Padrão: nenhum
? minimumIdle
Esta propriedade controla o número mínimo de conexões ociosas que o HikariCP tenta manter no pool. Se as conexões ociosas caírem abaixo desse valor e o total de conexões no pool for menor que maximumPoolSize , o HikariCP fará o possível para adicionar conexões adicionais de forma rápida e eficiente. No entanto, para máximo desempenho e capacidade de resposta a picos de demanda, recomendamos não definir esse valor e, em vez disso, permitir que o HikariCP atue como um pool de conexões de tamanho fixo . Padrão: igual a MaximumPoolSize
? maximumPoolSize
Esta propriedade controla o tamanho máximo que o conjunto pode atingir, incluindo conexões inativas e em uso. Basicamente, este valor determinará o número máximo de conexões reais com o backend do banco de dados. Um valor razoável para isso é melhor determinado pelo seu ambiente de execução. Quando o pool atingir esse tamanho e nenhuma conexão ociosa estiver disponível, as chamadas para getConnection() serão bloqueadas por até connectionTimeout milissegundos antes do tempo limite. Por favor, leia sobre o dimensionamento da piscina. Padrão: 10
? metricRegistry
Esta propriedade só está disponível por meio de configuração programática ou contêiner IoC. Esta propriedade permite que você especifique uma instância de um Codahale/Dropwizard MetricRegistry a ser usada pelo pool para registrar várias métricas. Consulte a página wiki de métricas para obter detalhes. Padrão: nenhum
? healthCheckRegistry
Esta propriedade só está disponível por meio de configuração programática ou contêiner IoC. Esta propriedade permite que você especifique uma instância de um Codahale/Dropwizard HealthCheckRegistry a ser usada pelo pool para relatar informações de saúde atuais. Consulte a página wiki do Health Checks para obter detalhes. Padrão: nenhum
? poolName
Esta propriedade representa um nome definido pelo usuário para o conjunto de conexões e aparece principalmente na criação de log e nos consoles de gerenciamento JMX para identificar conjuntos e configurações de conjunto. Padrão: gerado automaticamente
⏳ initializationFailTimeout
Esta propriedade controla se o pool "falhará rapidamente" se o pool não puder ser propagado com êxito com uma conexão inicial. Qualquer número positivo é considerado o número de milissegundos para tentar adquirir uma conexão inicial; o thread do aplicativo será bloqueado durante esse período. Se uma conexão não puder ser adquirida antes que esse tempo limite ocorra, uma exceção será lançada. Este tempo limite é aplicado após o período connectionTimeout . Se o valor for zero (0), o HikariCP tentará obter e validar uma conexão. Se uma conexão for obtida, mas falhar na validação, uma exceção será lançada e o pool não será iniciado. No entanto, se não for possível obter uma conexão, o pool será iniciado, mas os esforços posteriores para obter uma conexão poderão falhar. Um valor menor que zero ignorará qualquer tentativa inicial de conexão e o pool será iniciado imediatamente ao tentar obter conexões em segundo plano. Conseqüentemente, esforços posteriores para obter uma conexão poderão falhar. Padrão: 1
❎ isolateInternalQueries
Esta propriedade determina se o HikariCP isola consultas internas do pool, como o teste de conexão ativa, em sua própria transação. Como essas consultas normalmente são somente leitura, raramente é necessário encapsulá-las em sua própria transação. Esta propriedade só se aplica se autoCommit estiver desabilitado. Padrão: falso
❎ allowPoolSuspension
Esta propriedade controla se o conjunto pode ser suspenso e retomado por meio do JMX. Isto é útil para determinados cenários de automação de failover. Quando o pool for suspenso, as chamadas para getConnection() não atingirão o tempo limite e serão retidas até que o pool seja retomado. Padrão: falso
❎ readOnly
Esta propriedade controla se as conexões obtidas do pool estão no modo somente leitura por padrão. Observe que alguns bancos de dados não suportam o conceito de modo somente leitura, enquanto outros fornecem otimizações de consulta quando a Conexão está definida como somente leitura. Se você precisa ou não dessa propriedade, dependerá muito do seu aplicativo e banco de dados. Padrão: falso
❎ registerMbeans
Esta propriedade controla se os JMX Management Beans ("MBeans") são registrados ou não. Padrão: falso
? catalog
Esta propriedade configura o catálogo padrão para bancos de dados que suportam o conceito de catálogos. Se esta propriedade não for especificada, o catálogo padrão definido pelo driver JDBC será utilizado. Padrão: padrão do driver
? connectionInitSql
Esta propriedade define uma instrução SQL que será executada após cada criação de nova conexão antes de adicioná-la ao pool. Se este SQL não for válido ou lançar uma exceção, será tratado como uma falha de conexão e a lógica de nova tentativa padrão será seguida. Padrão: nenhum
? driverClassName
O HikariCP tentará resolver um driver através do DriverManager baseado apenas no jdbcUrl , mas para alguns drivers mais antigos o driverClassName também deve ser especificado. Omita esta propriedade, a menos que você receba uma mensagem de erro óbvia indicando que o driver não foi encontrado. Padrão: nenhum
? transactionIsolation
Esta propriedade controla o nível de isolamento de transação padrão das conexões retornadas do conjunto. Se esta propriedade não for especificada, o nível de isolamento de transação padrão definido pelo driver JDBC será utilizado. Utilize esta propriedade apenas se tiver requisitos de isolamento específicos que sejam comuns a todas as consultas. O valor desta propriedade é o nome constante da classe Connection , como TRANSACTION_READ_COMMITTED , TRANSACTION_REPEATABLE_READ , etc. Padrão: padrão do driver
⏳ validationTimeout
Esta propriedade controla o período máximo de tempo durante o qual uma conexão será testada quanto à atividade. Este valor deve ser menor que connectionTimeout . O tempo limite de validação mais baixo aceitável é 250 ms. Padrão: 5000
⏳ leakDetectionThreshold
Esta propriedade controla o período de tempo que uma conexão pode ficar fora do conjunto antes que uma mensagem seja registrada indicando um possível vazamento de conexão. Um valor 0 significa que a detecção de vazamento está desabilitada. O valor mais baixo aceitável para ativar a detecção de vazamento é 2.000 (2 segundos). Padrão: 0
➡ dataSource
Esta propriedade só está disponível por meio de configuração programática ou contêiner IoC. Esta propriedade permite que você defina diretamente a instância do DataSource a ser encapsulada pelo pool, em vez de fazer com que o HikariCP a construa por meio de reflexão. Isso pode ser útil em algumas estruturas de injeção de dependência. Quando esta propriedade for especificada, a propriedade dataSourceClassName e todas as propriedades específicas do DataSource serão ignoradas. Padrão: nenhum
? schema
Esta propriedade configura o esquema padrão para bancos de dados que suportam o conceito de esquemas. Se esta propriedade não for especificada, o esquema padrão definido pelo driver JDBC será utilizado. Padrão: padrão do driver
➡ threadFactory
Esta propriedade só está disponível por meio de configuração programática ou contêiner IoC. Esta propriedade permite definir a instância do java.util.concurrent.ThreadFactory que será usada para criar todos os threads usados pelo pool. É necessário em alguns ambientes de execução restrita onde os threads só podem ser criados através de um ThreadFactory fornecido pelo contêiner do aplicativo. Padrão: nenhum
➡ scheduledExecutor
Esta propriedade só está disponível por meio de configuração programática ou contêiner IoC. Esta propriedade permite definir a instância do java.util.concurrent.ScheduledExecutorService que será usada para diversas tarefas agendadas internamente. Se fornecer ao HikariCP uma instância ScheduledThreadPoolExecutor , é recomendado que setRemoveOnCancelPolicy(true) seja usado. Padrão: nenhum
➡ exceptionOverride
Esta propriedade só está disponível por meio de configuração programática ou contêiner IoC. Esta propriedade permite definir uma instância de uma classe, implementando a interface com.zaxxer.hikari.SQLExceptionOverride , que será chamada antes que uma conexão seja removida do pool devido a condições de exceção específicas. Normalmente, quando uma SQLException é lançada, as conexões são removidas do pool quando SQLStates ou ErrorCodes específicos estão presentes. O método adjudicate() será chamado na instância SQLExceptionOverride , que pode retornar um dos seguintes: Override.CONTINUE_EVICT . Override.DO_NOT_EVICT ou Override.MUST_EVICT . Exceto em casos muito específicos, Override.CONTINUE_EVICT deve ser retornado, permitindo a execução da lógica padrão de despejo/não despejo. Padrão: nenhum
? exceptionOverrideClassName
Esta propriedade permite especificar o nome de uma classe fornecida pelo usuário que implementa a interface com.zaxxer.hikari.SQLExceptionOverride . Uma instância da classe será instanciada pelo pool para julgar remoções de conexão. Consulte a propriedade exceptionOverride acima para obter uma descrição completa. Padrão: nenhum
O HikariCP tem muitos “botões” para girar, como você pode ver acima, mas comparativamente menos do que alguns outros pools. Esta é uma filosofia de design. A estética de design do HikariCP é o Minimalismo. Seguindo a filosofia de design simples é melhor ou menos é mais , alguns eixos de configuração são intencionalmente deixados de fora.
Muitos pools de conexões, incluindo Apache DBCP, Vibur, c3p0 e outros, oferecem cache PreparedStatement . HikariCP não. Por que?
Na camada do pool de conexões, PreparedStatements só pode ser armazenado em cache por conexão . Se o seu aplicativo tiver 250 consultas comumente executadas e um pool de 20 conexões, você está solicitando ao seu banco de dados que mantenha 5.000 planos de execução de consultas - e da mesma forma, o pool deve armazenar em cache esses muitos PreparedStatements e seus gráficos de objetos relacionados.
A maioria dos principais drivers JDBC de banco de dados já possui um cache de instruções que pode ser configurado, incluindo PostgreSQL, Oracle, Derby, MySQL, DB2 e muitos outros. Os drivers JDBC estão em uma posição única para explorar recursos específicos do banco de dados, e quase todas as implementações de cache são capazes de compartilhar planos de execução entre conexões . Isso significa que, em vez de 5.000 instruções na memória e planos de execução associados, suas 250 consultas comumente executadas resultam em exatamente 250 planos de execução no banco de dados. Implementações inteligentes nem mesmo retêm objetos PreparedStatement na memória no nível do driver, mas apenas anexam novas instâncias aos IDs de plano existentes.
Usar um cache de instrução na camada de pooling é um antipadrão e afetará negativamente o desempenho do seu aplicativo em comparação com os caches fornecidos pelo driver.
Assim como o cache de instruções, a maioria dos principais fornecedores de bancos de dados oferece suporte ao registro de instruções por meio de propriedades de seu próprio driver. Isso inclui Oracle, MySQL, Derby, MSSQL e outros. Alguns até oferecem suporte ao registro de consultas lento. Para os poucos bancos de dados que não oferecem suporte, diversas opções estão disponíveis. Recebemos um relatório de que o p6spy funciona bem e também observamos a disponibilidade de log4jdbc e jdbcdslog-exp.
Leia o Guia do Rapid Recovery para obter detalhes sobre como configurar seu driver e sistema para recuperação adequada de eventos de reinicialização do banco de dados e partição de rede.
Você pode usar a classe HikariConfig assim 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 exemplo específico do MySQL, NÃO COPIE VERBATIM.
ou instancie diretamente um HikariDataSource assim:
HikariDataSource ds = new HikariDataSource ();
ds . setJdbcUrl ( "jdbc:mysql://localhost:3306/simpsons" );
ds . setUsername ( "bart" );
ds . setPassword ( "51mp50n" );
...ou arquivo de propriedade baseado em:
// Examines both filesystem and classpath for .properties file
HikariConfig config = new HikariConfig ( "/some/path/hikari.properties" );
HikariDataSource ds = new HikariDataSource ( config );Exemplo de arquivo de propriedades:
dataSourceClassName =org.postgresql.ds.PGSimpleDataSource
dataSource.user =test
dataSource.password =test
dataSource.databaseName =mydb
dataSource.portNumber =5432
dataSource.serverName =localhost ou baseado em 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 ); Há também uma propriedade System disponível, hikaricp.configurationFile , que pode ser usada para especificar o local de um arquivo de propriedades. Se você pretende usar esta opção, construa uma instância HikariConfig ou HikariDataSource usando o construtor padrão e o arquivo de propriedades será carregado.
Dicas de desempenho do MySQL
Recomendamos usar dataSourceClassName em vez de jdbcUrl , mas qualquer um deles é aceitável. Diremos isso novamente, qualquer um deles é aceitável .
Nota: Usuários de configuração automática do Spring Boot, você precisa usar a configuração baseada em jdbcUrl .
Sabe-se que o MySQL DataSource está quebrado em relação ao suporte ao tempo limite da rede. Use a configuração jdbcUrl .
Aqui está uma lista de classes JDBC DataSource para bancos de dados populares:
| Banco de dados | Motorista | Classe DataSource |
|---|---|---|
| Apache Derby | Dérbi | org.apache.derby.jdbc.ClientDataSource |
| Pássaro de fogo | Gaio | org.firebirdsql.ds.FBSimpleDataSource |
| Chave inglesa do Google | Chave inglesa | 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 |
| Servidor SQL MS | Microsoft | com.microsoft.sqlserver.jdbc.SQLServerDataSource |
| Conector/J | ||
| Maria DB | Maria DB | org.mariadb.jdbc.MariaDbDataSource |
| Oráculo | Oráculo | 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 | SEIVA | com.sap.dbtech.jdbc.DriverSapDB |
| SQLite | xerial | org.sqlite.SQLiteDataSource |
| SyBase | jConectar | com.sybase.jdbc4.jdbc.SybDataSource |
Nota O Play 2.4 agora usa HikariCP por padrão. Um novo plugin surgiu para a estrutura do Play; jogar-hikaricp. Se você estiver usando a excelente estrutura do Play, seu aplicativo merece o HikariCP. Obrigado Equipe Edulify!
Um novo wrapper Clojure foi criado por tomekw e pode ser encontrado aqui.
Um novo wrapper JRuby foi criado por tomekw e pode ser encontrado aqui.
Grupo de discussão do Google HikariCP aqui, perguntas frequentes crescentes.
Não se esqueça do Wiki para obter informações adicionais, como:
⇒ Java 8+ (artefatos Java 6/7 estão em modo de manutenção)
⇒ biblioteca slf4j
Projetos de alto desempenho nunca podem ter ferramentas demais! Gostaríamos de agradecer às seguintes empresas:
Obrigado à ej-technologies pelo seu excelente perfilador completo, JProfiler.
YourKit oferece suporte a projetos de código aberto com seu Java Profiler completo. Clique no logotipo do YourKit abaixo para saber mais. 
Faça alterações e envie solicitações pull do branch dev em vez de master . Configure seu editor para usar espaços em vez de tabulações e siga o estilo aparente do código que você está editando. O branch dev é sempre mais "atual" que o master se você deseja viver a vida no limite.
