c3p0
1.0.0
c3p0 é uma biblioteca de pooling de conexões JDBC madura e altamente simultânea, com suporte para armazenamento em cache e reutilização de objetos PreparedStatement .
c3p0 está disponível como dependência gerenciada no Maven Central, [groupId: com.mchange, artifactId: c3p0] Para versões disponíveis, veja aqui.
Por favor, veja a documentação para mais.
Do instantâneo de desenvolvimento atual, aqui está o CHANGELOG mais recente.
Por favor, envie comentários e perguntas ao autor da biblioteca.
No entanto, tenha em mente que ele é um correspondente péssimo e basicamente um idiota.
Apesar disso, seu feedback é muito apreciado. Solicitações pull são aceitas com gratidão. Você também pode abrir problemas.
Obrigado pelo seu interesse em c3p0. Espero que você ache útil!
Por enquanto (v0.10.1), o c3p0 é construído em uma VM Java 11, visando arquivos de classe JDK 7 para compatibilidade contínua com aplicativos legados.
Para me lembrar de mudar para o Java 11, a compilação falhará com uma exceção se detectar uma versão inesperada.
Você pode comentar esse requisito no build.sc se desejar. É a linha que parece
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 conta com um excelente mill de ferramentas de construção.
Instale mill . Então, dentro deste diretório de repositório, execute
$ mill jar
Você encontrará o arquivo bruto como biblioteca out/jar.dest/out.jar .
Se você mantiver um repositório ivy local, poderá personalizar publishVersion em build.sc e executar
$ mill publishLocal
Para construir a documentação
$ mill doc.docroot
Você pode então abrir em seu navegador out/doc/docroot.dest/index.html
Por padrão, os testes esperam encontrar um banco de dados em jdbc:postgresql://localhost:5432/c3p0 . Como você pode ver, geralmente testo em um banco de dados postgres local. Você pode alterar isso na função forkArgs de build.sc .
Os testes do c3p0 são embaraçosamente informais. Existe um conjunto de testes junit, mas cobre uma fração muito pequena da funcionalidade do c3p0. Para executar isso, é só
$ mill test.test
Principalmente o c3p0 é testado executando alguns aplicativos de teste e variando a configuração ad hoc para ver como as coisas funcionam.
Se você acha que o c3p0 poderia/deveria ser testado de forma mais profissional e automática, eu também! Eu adoraria uma solicitação de pull.
build.sc contém muitos aplicativos de teste, mas os mais importantes são
$ mill test.c3p0Benchmark
Este é o c3p0 mais básico, comum e de teste de primeiro recurso. Ele executa e cronometra várias operações c3p0 diferentes e submete a biblioteca a um exercício muito bom
$ mill test.c3p0Load
Este coloca c3p0 sob carga de 100 threads, executando 1.000 operações de banco de dados cada, e então termina.
$ mill test.c3p0PSLoad
Este coloca c3p0 sob carga de 100 threads executando operações de banco de dados indefinidamente. Ele usa PreparedStatement para suas operações de banco de dados, portanto é uma boa maneira de exercitar o cache de instruções.
Você pode observar (a maior parte) a configuração do seu DataSource c3p0 ao testar, porque o c3p0 o registra em INFO na primeira tentativa de checkout Connection . Ao testar, verifique se você está trabalhando com a configuração esperada!
Os testes são configurados por argumentos de linha de comandos e por um arquivo c3p0.properties . Para brincar com configurações diferentes, edite test/resources-local/c3p0.properties . Verifique também o método forkArgs() em build.sc
Às vezes você quer testar a biblioteca com configuração patológica. Uma configuração patológica de linha de base é definida em test/resources-local-rough/c3p0.properties .
Para dar esse efeito, edite temporariamente build.sc :
override def runClasspath : T [ Seq [ PathRef ]] = T {
super .runClasspath() ++ localResources()
// super.runClasspath() ++ localResourcesRough()
}super.runClasspath() ++ localResources()super.runClasspath() ++ localResourcesRough() Então, é claro, você pode editar test/resources-local-rough/c3p0.properties .
Freqüentemente, você desejará concentrar o registro em uma classe ou recurso que está testando. Por padrão, os testes c3p0 são configurados para usar java.util.logging. e ser configurado pelo arquivo test/conf-logging/logging.properties .
É claro que você pode alterar a configuração (em c3p0.properties ) para usar outra biblioteca de log, se desejar, mas pode ser necessário modificar a compilação para trazer bibliotecas de log de terceiros e configurar essas bibliotecas à sua maneira.
Como o c3p0 atualmente é compilado no Java 11, mas o c3p0-loom requer o Java 21, o c3p0 loom é um projeto separado.
É apenas um projeto de moinho paralelo. As instruções acima se aplicam (exceto que c3p0-loom não possui documentação independente para construção).
c3p0 é licenciado sob LGPL v.2.1 ou EPL v.1.0, conforme sua opção. Você também pode optar por licenciar o c3p0 sob qualquer versão da LGPL superior à v.2.1.
Observação: o c3p0 teve uma boa experiência com o relato de uma vulnerabilidade de segurança por meio do Central Security Project da Sonatype. Se você encontrar um problema de segurança c3p0, considere relatá-lo via https://hackerone.com/central-security-project
