나는 연결 풀 옵션을 조사해 왔으며 Tomcat JNDI 연결 풀 접근 방식의 차이점이 Spring/Hibernate와 비교하여 다소 불분명하다. 같은 해결책.Tomcat JNDI 기반과 Spring/Hibernate DS 기반 연결 풀링의 차이점
1, 2을 사용하여 풀링을 달성 할 수 있지만 특정 응용 프로그램은 우리가 가지고있는 제약 사항을 감안할 때 Tomcat을 사용하여 더 잘 제공 할 수 있습니다.
약 읽을 내용은 just stick with Spring/Hibernate입니다.
각 접근법 사이에 언급 할만한 주목할만한 차이점이 있습니까? 다른 하나 (또는 둘 다)에 대한 다른 사람의 개인적인 경험 - 나는 수년간 Spring/Hibernate를 성공적으로 사용 해왔다.
두 가지 방법은 상호 보완 적이며 상호 배타적 인 것이 아닙니다. 프로덕션 시스템에서 Spring/Hibernate는 appserver로부터 connection pool에 대한 참조를 javax.sql.DataSource 형태로 얻을 것입니다. 일반적으로 JNDI 트리에서이를 찾습니다. 일반적으로 연결 풀 및 연결을 관리하는 응용 서버의 "작업"으로 간주됩니다.
JNDI는 공유를 위해 개체를 등록하기위한 장소 일 뿐이며 모든 연결 풀 메커니즘을 위임한다는 것을 기억하십시오. 앱 서버는 풀과 애플리케이션을 생성하고 (Spring/Hibernate/any를 통해) 그것을 사용한다.
그러나 응용 프로그램이 연결 풀을 직접 구성하고 관리하는 것은 유효합니다. 하지만 이것은 애플리케이션 서버에 대한 의존도가 낮아 애플리케이션에 대한 작업이 조금 더 많음을 의미합니다.
충분히 공정하고 말이됩니다. 이제 내가 Tomcat JNDI 풀링 기반으로 갔다 고 가정하면, 따라서 Tomcat의 JNDI 풀링 풀 위에 풀링하지 않기 위해 스프링 풀링 설정을 해제해야한다고 가정합니다 ...? –
Spring은 연결 풀 구현을 가지고 있지 않으며,'DataSource' 객체를 사용합니다. JNDI를 통해 Tomcat이 제공하는 연결 풀인 경우, 훨씬 더 좋습니다. – skaffman
사실, 내가 최대 절전 모드를 의미했다는 미안. –
JNDI 연결 풀을 사용하면 컨테이너 전체 (예 : 여러 웹 응용 프로그램간에 공유)가 될 것입니다. Spring 컨텍스트에서 연결 풀을 정의하면 컨텍스트 내에서 연결 풀이 정의됩니다 (예 : 응용 프로그램 전체). 나는 Tomcat + JNDI 옵션을 사용하지 않았기 때문에 좋은 조언을 드릴 수는 없다. –