c3p0은 PreparedStatement
개체의 캐싱 및 재사용을 지원하는 성숙한 동시성 JDBC 연결 풀링 라이브러리입니다.
c3p0은 Maven Central에서 관리되는 종속성으로 사용할 수 있습니다. [groupId: com.mchange, artifactId: c3p0]
사용 가능한 버전은 여기를 참조하세요.
자세한 내용은 설명서를 참조하세요.
현재 개발 스냅샷 에서 최신 CHANGELOG가 있습니다.
의견이나 질문은 도서관 저자에게 보내주세요.
그러나 그는 형편없는 특파원이고 기본적으로 병신이라는 점을 명심하시기 바랍니다.
그럼에도 불구하고 귀하의 피드백은 매우 감사드립니다. Pull Request는 감사하게 받아들여집니다. 문제를 열 수도 있습니다.
c3p0에 관심을 가져주셔서 감사합니다. 나는 당신이 그것이 유용하다고 생각하기를 바랍니다!
현재(v0.10.1) c3p0은 Java 11 VM 아래에 구축되어 레거시 앱과의 지속적인 호환성을 위해 JDK 7 클래스 파일을 대상으로 합니다.
Java 11로 전환하라는 알림을 보내기 위해 예상치 못한 버전이 감지되면 예외가 발생하면서 빌드가 실패합니다.
원하는 경우 build.sc
에서 이 요구 사항에 대해 설명을 추가할 수 있습니다. 보이는 라인이에요
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은 뛰어난 빌드 도구 mill
사용합니다.
mill
설치합니다. 그런 다음 이 저장소 디렉터리 내에서 다음을 실행합니다.
$ mill jar
out/jar.dest/out.jar
라이브러리로 원시 파일을 찾을 수 있습니다.
로컬 아이비 저장소를 유지 관리하는 경우 build.sc
에서 publishVersion
사용자 정의한 다음 실행할 수 있습니다.
$ mill publishLocal
문서를 작성하려면
$ mill doc.docroot
그런 다음 브라우저에서 out/doc/docroot.dest/index.html
열 수 있습니다.
기본적으로 테스트에서는 jdbc:postgresql://localhost:5432/c3p0
에서 데이터베이스를 찾을 것으로 예상합니다. 보시다시피 저는 보통 로컬 postgres 데이터베이스를 대상으로 테스트합니다. build.sc
의 forkArgs
함수에서 이를 변경할 수 있습니다.
c3p0의 테스트는 음, 당황스러울 정도로 비공식적입니다. junit 테스트 모음이 있지만 c3p0 기능의 아주 작은 부분을 다루고 있습니다. 그것을 실행하려면, 그것은 단지
$ mill test.test
대부분 c3p0은 몇 가지 테스트 애플리케이션을 실행하고 임시 구성을 변경하여 작동 방식을 확인하여 테스트됩니다.
c3p0을 보다 전문적이고 자동으로 테스트할 수 있거나 테스트해야 한다고 생각하신다면 저도 마찬가지입니다! 풀 리퀘스트를 받고 싶습니다.
build.sc
에는 많은 테스트 애플리케이션이 포함되어 있지만 가장 중요한 것은
$ mill test.c3p0Benchmark
이것은 c3p0의 가장 기본적이고 일반적인 테스트 방법입니다. 다양한 c3p0 작업을 실행하고 시간을 측정하며 라이브러리에 꽤 좋은 작업을 수행합니다.
$ mill test.c3p0Load
이는 c3p0에 각각 1000개의 데이터베이스 작업을 수행하는 100개의 스레드를 로드한 다음 종료됩니다.
$ mill test.c3p0PSLoad
이로 인해 c3p0은 데이터베이스 작업을 무기한 수행하는 100개 스레드의 로드를 받게 됩니다. 데이터베이스 작업을 위해 PreparedStatement
사용하므로 명령문 캐시를 실행하는 좋은 방법입니다.
c3p0이 첫 번째 Connection
체크아웃 시도 시 INFO
에 이를 기록하므로 테스트할 때 c3p0 DataSource
의 구성(대부분)을 관찰할 수 있습니다. 테스트할 때 예상한 구성으로 작업하고 있는지 확인하세요!
테스트는 명령줄 인수와 c3p0.properties
파일로 구성됩니다. 다른 구성을 사용하려면 test/resources-local/c3p0.properties
편집하세요. 또한 build.sc
에서 forkArgs()
메서드를 확인하세요.
때로는 병리학적 구성을 통해 라이브러리를 테스트하고 싶을 때도 있습니다. 기본 병리학적 구성은 test/resources-local-rough/c3p0.properties
에 정의되어 있습니다.
이 효과를 적용하려면 임시로 build.sc
편집하세요.
override def runClasspath : T [ Seq [ PathRef ]] = T {
super .runClasspath() ++ localResources()
// super.runClasspath() ++ localResourcesRough()
}
super.runClasspath() ++ localResources()
주석 처리super.runClasspath() ++ localResourcesRough()
에서 주석 처리를 제거하세요. 그런 다음 test/resources-local-rough/c3p0.properties
편집할 수 있습니다.
종종 테스트 중인 클래스나 기능에 로깅을 집중하고 싶을 것입니다. 기본적으로 c3p0 테스트는 java.util.logging.
, test/conf-logging/logging.properties
파일로 구성됩니다.
물론 원하는 경우 다른 로깅 라이브러리를 사용하도록 구성( c3p0.properties
)을 변경할 수 있지만 타사 로깅 라이브러리를 가져오고 해당 라이브러리를 고유한 방식으로 구성하도록 빌드를 수정해야 할 수도 있습니다.
c3p0은 현재 Java 11에서 빌드되지만 c3p0-loom에는 Java 21이 필요하므로 c3p0 loom은 별도의 프로젝트입니다.
그것은 단지 평행밀 프로젝트일 뿐입니다. 위 지침이 적용됩니다(단, c3p0-loom
빌드할 독립적인 문서가 없습니다).
c3p0은 귀하의 선택에 따라 LGPL v.2.1 또는 EPL v.1.0에 따라 라이센스가 부여됩니다. v.2.1보다 높은 LGPL 버전에서 c3p0 라이센스를 선택할 수도 있습니다.
참고: c3p0은 Sonatype의 중앙 보안 프로젝트를 통해 보안 취약점을 보고한 좋은 경험을 갖고 있습니다. c3p0 보안 문제를 발견하면 https://hackerone.com/central-security-project를 통해 보고해 보세요.