현재 최대 절전 모드를 배우고 애플리케이션 서버의 연결 풀을 사용하도록 설정하는 나의 모험에서, 대부분의 예제와 리소스는 SessionFactory를 프로세스의 Appserver에있는 JNDI 리소스에 바인딩하는 방향으로 안내합니다.Hibernate SessionFactory를 JNDI 리소스에 바인드하는 이유는 무엇입니까?
나는 이것의 이점이 무엇인지 궁금합니다. 이후 당신이 일을하지 않고 연결 풀에 액세스 할 수 있습니다.
JNDI를 사용하는 것과 같은 이유 때문에 애플리케이션에서 구성을 배포 환경으로 옮기는 것이 좋습니다.
JNDI를 사용하면 기본적으로 "이 응용 프로그램에는 SessionFactory이 필요하며 그 이름은 X가되어야합니다"라고 말하면 응용 프로그램 서버에 X가 구성된 SessionFactory이있는 한 만족할 것입니다. 외부화의이 종류는 여러 가지 매력적인 이점이 있습니다
당신은 다른 기계에 격렬하게 서로 다른 구성을 사용할 수 있습니다 (생산 및 QA가 오라클을 사용하는 개발자는 HSQL, ... 사용).
빌드 프로세스가 구성을 인식하도록 만들 필요가 없습니다 (더 이상 ant war_for_qa 또는 Maven 프로파일을 사용하지 않음).
구성을 버전 관리로 확인하고 싶지 않으므로 라이브 데이터베이스 암호를 액세스 할 수있는 (또는 가질 수있는) 모든 임시 직원, 인턴, 컨설턴트 또는 전직원에게 알 수 없습니다 저장소.
"데이터베이스 로그인 구성, WAR 파일의 foo.properties 파일 편집"과 같은 항목은 설치/구성 지침에 포함되지 않으므로 필연적으로 최악의 경우 프로덕션 서버에서 구성을 필연적으로 덮어 쓰게됩니다 왜냐하면 주말 내내 일해온 시스템 관리자가 일요일 오후에 커피가 없어 졌기 때문에 편집되지 않은 WAR를 배포하기 때문입니다.
JNDI는 새의 devs/관리자가 자신의 집-brewn의 단점을 배우고 훈련 이틀을 필요로하지 않음을 의미 자바에서이 구체화을하는 "표준"방법, 될 일이 구성 시스템은 실제로 매우 똑똑하지만 이상한 버그가 있습니다. 아무도 조사하지 않으려 고합니다. 정말 이상합니다. 아주 간단한 해결 방법 인 & c가 있습니다.
관련 : 그 @gustafcWhat is the purpose of JNDI?
내가 생각 것이었다. 내가 다른 것을 놓치고 있는지 확실하지 않았다. 우리는 연결 풀에 JNDI를 사용하고 있습니다. 따라서 SessionFactory를 응용 프로그램 서버로 이동하는 추가 이점이 있는지 궁금합니다. 우리의 경우에는 그 구성이 모든 서버에서 똑같기 때문에 거기에있을 것이라고는 생각하지 않습니다. 그건 그렇고, 당신의 대답은 아마도 제가 알기에 아주 명확하고 유익한 대답 일 것입니다. –
동일한 서버에 배포 된 여러 응용 프로그램에서 사용할 수 있도록하는 것이 주 목적입니다. 이 경우 큰 이점은 SF의 공유 된 2 차 레벨 캐시입니다. 우리 SF는 하나의 응용 프로그램 만 배포 했으므로'@ Singleton'' @ Startup'' @ EJB' 내에 있습니다. – djmj
@djmj, 실현 가능하지만 솔직히 어떻게 응용 프로그램 서버가 이걸 처리하는지 모르겠다. 외부에서 정의 된 Hibernate/JPA 설정을 사용하는 응용 프로그램을 실행 한 적이 없기 때문에 대부분의 응용 프로그램은 사용자가 설명하는 방식으로 배포되는 것처럼 보입니다. 안정성, 보안 등에 영향을 미친다는 것을 상상할 수 있습니다. 따라서 공유 된 2 차 수준 캐시를 사용하지 않습니다. – gustafc