Hibernate가 많은 다른 환경들에서 동작하도록 설계되어 있으므로, 많은 개수의 구성 파라미터들이 존재한다. 다행히 대부분은 유의미한 디폴트 값들이고 Hibernate는 다양한 옵션들을 보여주는 etc/ 내의 예제 파일 hibernate.properties로 배포된다. 당신은 단지 당신의 classpath 경로 속에 그 파일을 집어넣고 그것을 커스트마이징하기만 해야 한다. org.hibernate.cfg.Configuration의 인스턴스는 어플리케이션의 Java 타입들을 SQL 데이터베이스 타입으로의 전체 매핑 집합을 표현한다. Configuration은 (불변의) SessionFactory를 빌드하는데 사용된다. 매핑들은 여러 XML 매핑 파일들로부터 컴파일 된다. 당신은 Configuration 인스턴스를 초기화 시키고 XML 매핑 문서들을 지정함으로써 Configuration 인스턴스를 얻을 수 있다. 만일 매핑 파일들이 classpath 내에 있다면, addResource()를 사용하라: (때때로 더 나은) 다른 방법은 매핑된 클래스를 지정하는 것이고, Hibernate로 하여금 당신을 위해 매핑 문서를 찾도록 하라: 그때 Hibernate는 classpath 내에서 /org/hibernate/auction/Item.hbm.xml과 /org/hibernate/auction/Bid.hbm.xml로 명명된 매핑 파일들을 룩업할 것이다. 이 접근법은 임의의 하드코딩된 파일 이름들을 제거한다. Configuration은 또한 구성 프로퍼티들을 지정하는 것을 허용해준다: 이것은 컨피그레이션 프로퍼티들을 Hibernate에 전달하는 유일한 방법이 아니다. 여러 가지 옵션들은 다음을 포함한다: java.util.Properties의 인스턴스를 Configuration.setProperties()에 전달한다 . classpath의 루트 디렉토리에 hibernate.properties를 위치지운다. java -Dproperty=value를 사용하여 System 프로퍼티들을 설정한다. hibernate.cfg.xml에 <property> 요소들을 포함한다 (나중에 논의됨). 당신이 빠르게 시작하고 원할 경우 hibernate.properties는 가장 쉬운 접근법이다. Configuration은 시작 시(startup-time) 객체로서 일단 SessionFactory가 생성되면 폐기되게끔 예정되어 있다. 모든 매핑들이 Configuration에 의해 파싱되었을 때, 어플리케이션은 Session 인스턴스들에 대한 팩토리를 얻어야 한다. 이 팩토리는 모든 어플리케이션 쓰레드들에 의해 공유되도록 고안되었다: 하지만 Hibernate는 당신의 어플리케이션이 하나 이상의 SessionFactory를 초기화 시키는 것을 허용한다. 이것은 당신이 하나 이상의 데이터베이스를 사용하는 경우에 유용하다. 대개 당신은 SessionFactory로 하여금 당신을 위한 JDBC 커넥션들을 생성시키고 풀링시키는 것을 원한다. 만일 당신이 이 접근법을 취할 경우, 한 개의 Session을 여는 것은 다음과 같이 간단하다: 당신이 데이터베이스에 대한 접근을 요청하는 어떤 것을 행하자 마자, 한 개의 JDBC 커넥션이 그 풀로부터 얻어질 것이다. 이것이 동작하도록 하기 위해서, 우리는 몇몇 JDBC 커넥션 프로퍼티들을 Hibernate에 전달할 필요가 있다. 모든 Hibernate 프로퍼티 이름들과 의미론들은 org.hibernate.cfg.Environment 클래스 상에 정의되어 있다. 우리는 이제 JDBC 커넥션 구성을 위한 가장 중요한 설정들을 설명할 것이다. 만일 당신이 다음 프로퍼티들을 설정할 경우 Hibernate는 java.sql.DriverManager를 사용하여 커넥션들을 얻을 것이다(그리고 풀링시킬 것이다): 프로퍼티 이름 용도 hibernate.connection.driver_class jdbc 드라이버 클래스 hibernate.connection.url jdbc URL hibernate.connection.username 데이터베이스 사용자 hibernate.connection.password 데이터베이스 사용자 패스워드 hibernate.connection.pool_size 풀링된 커넥션들의 최대 개수 하지만 Hibernate 자신의 커넥션 풀링 알고리즘은 아주 기본적이다. 그것은 당신이 시작하는 것을 도와주려고 의도되었고 제품 시스템 용도 또는 퍼포먼스 테스트용으로는 고안되지 않았다. 최상의 퍼포먼스와 안정성을 위해서는 제 3의 풀을 사용하라. 즉 hibernate.connection.pool_size 프로퍼티를 커넥션 풀 지정 설정들로 대체하라. 이것은 Hibernate의 내부 pool을 오프시킬 것이다. 예를 들어 당신은 C3P0를 사용할 수도 있다. C3P0는 lib 디펙토리 속에 Hibernate에 배포된 오픈 소스 JDBC 커넥션 풀이다. 당신이 hibernate.c3p0.* 프로퍼티들을 설정할 경우 Hibernate는 커넥션 풀링을 위해 그것의 C3P0ConnectionProvider를 사용할 것이다. 만일 당신이 Proxool을 사용하고자 원할 경우 패키지화 된 hibernate.properties를 참조하고 추가 정보는 Hibernate 웹 사이트를 참조하라. 다음은 C3P0에 대한 사용하는 예제 hibernate.properties 파일이다: 어플리케이션 서버 내부의 용도로, 당신은 JNDI로 등록된 어플리케이션 서버 Datasource로부터 커넥션을 얻기 위해 항상 Hibernate를 구성해야 한다. 당신은 적어도 다음 프로퍼티들 중 하나를 최소한으로 설정할 필요가 있을 것이다. 프로퍼티 이름 용도 hibernate.connection.datasource 데이터소스 JNDI 이름 hibernate.jndi.url JNDI 프로바이더의 URL (옵션) hibernate.jndi.class JNDI InitialContextFactory의 클래스 (옵션) hibernate.connection.username 데이터베이스 사용자 (옵션) hibernate.connection.password 데이터베이스 사용자 패스워드 (옵션) 다음은 어플리케이션 서버 제공 JNDI 데이터소스용 예제 hibernate.properties 파일이다: JNDI datasource로부터 얻어진 JDBC 커넥션들은 어플리케이션 서버의 컨테이너에 의해 관리되는 트랜잭션들에 자동적으로 참여할 것이다. 임의의 커넥션 프로퍼티들은 프로퍼티 이름 앞에 "hibernate.connnection"을 첨가하여 부여될 수 있다. 예를 들어 당신은 hibernate.connection.charSet을 사용하여 charSet을 지정할 수도 있다. 당신은 org.hibernate.connection.ConnectionProvider 인터페이스를 구현함으로써 JDBC 커넥션들을 얻는 당신 자신의 플러그인 방도를 정의할수도 있다. 당신은 hibernate.connection.provider_class를 설정하여 맞춤형 구현을 선택할 수도 있다. 실행 시에 Hibernate의 행위를 제어하는 많은 다른 프로퍼티들이 존재한다. 모든 것이 옵션이지만 합당한 디폴트 값들을 갖는다. 경고: 이들 프로퍼티들 중 몇몇은 "system-level" 전용이다. 시스템 레벨 프로퍼티들은 오직 java -Dproperty=value 또는 hibernate.properties를 통해서만 설정될 수 있다. 그것들은 위에 설명된 다른 기법들에 의해 설정될 수 없다. 프로퍼티 이름 용도 hibernate.dialect 특정 관계형 데이터베이스에 최적화 된 SQL을 생성시키는 것을 Hibernate에게 허용해주는 Hibernate Dialect의 클래스명. 예. full.classname.of.Dialect hibernate.show_sql 모든 SQL 문장들을 콘솔에 기록한다. 예. true | false hibernate.default_schema 생성된 SQL 내에 주어진 schema/tablespace로서 수식이 없는 테이블이름들을 수식한다. 예. SCHEMA_NAME hibernate.default_catalog 주어진 SQL 내에 주어진 카타록으로서 수식이 없는 테이블이름들을 수식한다. 예. CATALOG_NAME hibernate.session_factory_name SessionFactory는 그것이 생성된 후에 JNDI 내에서 이 이름에 자동적으로 바인드 될 것이다. 예. jndi/composite/name hibernate.max_fetch_depth single-ended 연관관계들(one-to-one, many-to-one)의 경우에 outer join fetch 트리의 최대 "깊이"를 설정한다. 0은 디폴트 outer join fetching을 사용불가능하게 만든다. 예. 0과 3 사이의 값들이권장된다 hibernate.default_batch_fetch_size 연관들의 Hibernate 배치 페칭에 대한 디폴트 크기를 설정한다. 예. 권장되는 값들은 4, 8, 16 hibernate.default_entity_mode 이 SessionFactory로부터 열려진 모든 세션들에 대해 엔티티 표현을 디폴트 모드로 설정한다 dynamic-map, dom4j, pojo hibernate.order_updates 업데이트 중인 항목들의 프라이머리 키 값에 의해 SQL 업데이트들이 순서(ordering)지워지도록 Hibernate에게 강제시킨다. 이것은 고도의 동시성 시스템들에서 더 적은 트랜잭션 데드락(deadlock)들로 귀결될 것이다 예. true | false hibernate.generate_statistics 이용 가능하게 되면, Hibernate는 퍼포먼스 튜닝에 유용한 통계들을 수집할 것이다. 예. true | false hibernate.use_identifer_rollback 이용 가능하게 되면, 객체가 삭제될 때 생성된 식별자 프로퍼티들은 디폴트 값들로 재설정될 것이다. 예. true | false hibernate.use_sql_comments 이용 가능하게 되면, Hibernate는 보다 쉬운 디버깅을 위해 SQL 내에 주석들을 생성시킬 것이다. 디폴트는 false. 예. true | false 프로퍼티 이름 용도 hibernate.jdbc.fetch_size 0 아닌 값은 JDBC fetch 사이즈를 결정한다(Statement.setFetchSize()을 호출한다 ). hibernate.jdbc.batch_size 0 아닌 값은 Hibernate에 의한 JDBC2 배치 업데이트의 사용을 이용 가능하게 한다. 예. 5와 30 사이의 값들이 권장된다 hibernate.jdbc.batch_versioned_data 당신의 JDBC 드라이버가 executeBatch()로부터 정확한 행 카운트들을 반환할 경우에 이 프로퍼티를 true로 설정하라(대개 이 옵션을 사용 가능하게 하는 것이 안전하다). 그러면 Hibernate는 자동적으로 버전화 된 데이터에 대해 배치화된(batched) DML을 사용할 것이다. 디폴트는 false. 예. true | false hibernate.jdbc.factory_class 맞춤형 Batcher를 선택한다. 대부분의 어플리케이션들은 이 구성 프로퍼티를 필요로 하지 않을 것이다. 예. classname.of.Batcher hibernate.jdbc.use_scrollable_resultset Hibernate에 의한 JDBC2 스크롤 가능한 결과셋들의 사용을 가능하게 해준다. 이 프로퍼티는 사용자가 제공한 JDBC커넥션들을 사용할 때에만 필수적이고, 그 밖의 경우 Hibernate는 커넥션 메타데이터를 사용한다. 예. true | false hibernate.jdbc.use_streams_for_binary binary 또는 serializable 타입들을 JDBC로 기록하고 /JDBC로부터 binary 또는 serializable 타입들을 읽어들일 때 스트림들을 사용한다(시스템-레벨 프로퍼티). 예. true | false hibernate.jdbc.use_get_generated_keys insert 후에 고유하게 생성된 키들을 검색하는데 JDBC3 PreparedStatement.getGeneratedKeys()의 사용을 이용 가능하도록 만든다. JDBC3+ 드라이버와 JRE1.4+를 필요로 하고, 당신의 드라이버가 Hibernate 식별자 생성자들에 문제가 있을 경우에 false로 설정하라. 디폴트로 커넥션 메타 데이터를 사용하여 드라이버 가용성들을 결정하려고 시도하라. 예. true|false hibernate.connection.provider_class Hibernate에 JDBC 커넥션들을 제공하는 맞춤형 ConnectionProvider의 클래스명. 예. classname.of.ConnectionProvider hibernate.connection.isolation JDBC transaction isolation 레벨을 설정한다. 의미있는 값들로 java.sql.Connection을 체크하지만 대부분의 데이터베이스들이 모든 격리(isolate) 레벨들을 지원하지 않음을 노트하라. 예. 1, 2, 4, 8 hibernate.connection.autocommit JDBC 풀링된 커넥션들에 대해 자동커밋을 이용 가능하도록 한다(권장되지 않음). 예. true | false hibernate.connection.release_mode Hibernate가 JDBC 커넥션들을 해제하게 될 시점을 지정한다. 디폴트로 한 개의 JDBC 커넥션은 그 세션이 명시적으로 닫히거나 연결해제되기 전까지 보관된다. 어플리케이션 트랜잭션 서버 JTA 데이터소스의 경우, 당신은 모든 JDBC 호출 후에 커넥션들을 과감하게 해제시키기 위해 after_statement를 사용해야 한다. 비-JTA 연결의 경우, after_transaction을 사용하여 각각의 트랜잭션의 끝에서 커넥션들을 해제시키는 것이 종종 의미가 있다. auto는 JTA 및 CMT 트랜잭션 방도들의 경우에 after_statement를 선택하고 JDBC 트랜잭션 방도에 대해 after_transaction를 선택할 것이다. eg. on_close (디폴트) | after_transaction | after_statement | auto hibernate.connection.<propertyName> JDBC 프로퍼티 propertyName을 DriverManager.getConnection()에 전달한다. hibernate.jndi.<propertyName> propertyName 프로퍼티를 JNDI InitialContextFactory에 전달한다. 프로퍼티 이름 용도 hibernate.cache.provider_class 맞춤형 CacheProvider의 클래스명. 예. classname.of.CacheProvider hibernate.cache.use_minimal_puts 읽기가 매우 빈번한 경우에, 쓰기를 최소화 시키기 위해 second-level 캐시 연산을 최적화 시킨다. 이 설정은 Hibernate3에서 클러스터링 된 캐시들에 가장 유용하고, Hibernate3에서는 클러스터링된 캐시 구현들에 대해 디폴트로 이용 가능하다. 예. true|false hibernate.cache.use_query_cache 질의 캐시를 가능하게 만든다. 개별 질의들은 여전히 캐시 가능한 것으로 설정되어야 한다. 예. true|false hibernate.cache.use_second_level_cache second-level 캐시를 완전히 사용 불가능하게 하는데 사용될 수 있고, 그것은 <cache> 매핑을 지정하는 클래스들에 대해 디폴트로 이용 가능이다. 예. true|false hibernate.cache.query_cache_factory 맞춤형 QueryCache 인터페이스의 클래스명. 디폴트는 미리 빌드된 StandardQueryCache. 예. classname.of.QueryCache hibernate.cache.region_prefix second-level 캐시 영역 이름들에 사용할 접두어. 예. prefix hibernate.cache.use_structured_entries 인간에게 보다 더 친숙한 형식으로 second-level 캐시 속에 데이터를 저장하도록 Hibernate에게 강제시킨다.. 예. true|false 프로퍼티 이름 용도 hibernate.transaction.factory_class Hibernate Transaction API 에 사용할 TransactionFactory의 클래스 이름.(디폴트는 JDBCTransactionFactory). 예. classname.of.TransactionFactory jta.UserTransaction 어플리케이션 서버로부터 JTA UserTransaction을 얻기 위해 JTATransactionFactory에 의해 사용되는 JNDI 이름. 예. jndi/composite/name hibernate.transaction.manager_lookup_class TransactionManagerLookup의 클래스명- JVM 레벨의 캐싱이 이용 가능할 때 또는 JTA 환경에서 hilo generator를 사용할 때 필요하다. 예. classname.of.TransactionManagerLookup hibernate.transaction.flush_before_completion 만일 사용가능토록 하면, 트랜잭션의 before completion 단계 동안에 세션이 자동적으로 flush 될 것이다. (CMT에 대해 Hibernate를 사용할 때 매우 유용하다.) 예. true | false hibernate.transaction.auto_close_session 만일 사용가능토록 하면, after completion 단계 동안에 세션이 자동적으로 닫혀질 것이다. (CMT에 대해 Hibernate를 사용할 때 매우 유용하다.) 예. true | false 프로퍼티 이름 용도 hibernate.query.factory_class Chooses the HQL 파서 구현을 선택한다. 예. org.hibernate.hql.ast.ASTQueryTranslatorFactory 또는 org.hibernate.hql.classic.ClassicQueryTranslatorFactory hibernate.query.substitutions Hibernate 질의들 내의 토큰들로부터 SQL 토큰들로의 매핑(예를 들어 토큰들은 함수 이름 또는 리터럴 이름일 수 있다). 예. hqlLiteral=SQL_LITERAL, hqlFunction=SQLFUNC hibernate.hbm2ddl.auto SessionFactory가 생성될 때 스키마 DDL을 데이터베이스로 자동적으로 내보낸다. create-drop의 경우, SessionFactory가 명시적으로 닫혀질 때,, 데이터베이스 스키마가 드롭될 것이다. 예. update | create | create-drop hibernate.cglib.use_reflection_optimizer 런타임 reflection 대신에 CGLIB의 사용을 가능하도록 만든다(시스템 레벨 프로퍼티). Reflection은 문제가 발생할 시에 때때로 유용할 수 있고, 당신이 optimizer를 사용하지 않을 경우조차도 Hibernate는 항상 필요로 함을 유의하라. 당신은 hibernate.cfg.xml 속에 이 프로퍼티를 설정할수 없다. 예. true | false 당신은 항상 당신의 데이터베이스를 위해 hibernate.dialect 프로퍼티를 정확한 org.hibernate.dialect.Dialect 서브클래스로 설정해야 한다. 만일 당신이 dialect를 지정할 경우, 당신이 프로퍼티들을 수작업으로 지정하는 노력을 절약하도록 Hibernate는 위에 열거된 다른 프로퍼티들 중 몇몇에 대해 의미있는 디폴트들을 사용할 것이다. RDBMS Dialect DB2 org.hibernate.dialect.DB2Dialect DB2 AS/400 org.hibernate.dialect.DB2400Dialect DB2 OS390 org.hibernate.dialect.DB2390Dialect PostgreSQL org.hibernate.dialect.PostgreSQLDialect MySQL org.hibernate.dialect.MySQLDialect MySQL with InnoDB org.hibernate.dialect.MySQLInnoDBDialect MySQL with MyISAM org.hibernate.dialect.MySQLMyISAMDialect Oracle (any version) org.hibernate.dialect.OracleDialect Oracle 9i/10g org.hibernate.dialect.Oracle9Dialect Sybase org.hibernate.dialect.SybaseDialect Sybase Anywhere org.hibernate.dialect.SybaseAnywhereDialect Microsoft SQL Server org.hibernate.dialect.SQLServerDialect SAP DB org.hibernate.dialect.SAPDBDialect Informix org.hibernate.dialect.InformixDialect HypersonicSQL org.hibernate.dialect.HSQLDialect Ingres org.hibernate.dialect.IngresDialect Progress org.hibernate.dialect.ProgressDialect Mckoi SQL org.hibernate.dialect.MckoiDialect Interbase org.hibernate.dialect.InterbaseDialect Pointbase org.hibernate.dialect.PointbaseDialect FrontBase org.hibernate.dialect.FrontbaseDialect Firebird org.hibernate.dialect.FirebirdDialect 만일 당신의 데이터베이스가 ANSI, Oracle, 또는 Sybase 스타일의 outer join들을 지원할 경우, outer join fetching은 (데이터베이스 그 자체에 의해 보다 더 많은 작업이 수행되는 비용으로) 데이터베이스로의 그리고 데이터베이스로부터의 라운드 트립들의 개수를 제한함으로써 종종 퍼포먼스를 증가시킬 것이다. Outer join fetching은 many-to-one, one-to-many, many-to-many,one-to-one 연관관계들이 에 의해 연결된 객체들의 전체 그래프가 하나의 SQL SELECT 속에서 검색되게끔 허용해준다. Outer join fetching은 hibernate.max_fetch_depth 프로퍼티를 0으로 설정함으로써 전역적으로 사용 불가능하게 할 수 있다. 1 이상의 값을 설정하는 것은 fetch="join"으로 매핑되었던 모든 one-to-one 및 many-to-one 연관관계들에 대해 outer join fetching을 사용 가능하도록 만든다. 추가 정보는 를 보라. Oracle은 JDBC 드라이버 로/부터 전달되는 byte 배열들의 크기를 제한시킨다. 만일 당신이 binary 또는 serializable 타입의 대형 인스턴스를 사용하고자 원할 경우에, 당신은 hibernate.jdbc.use_streams_for_binary를 사용 가능하게 해야 할 것이다. 이것은 오직 시스템 레벨 설정이다. hibernate.cache 접두어가 붙은 프로퍼티들은 Hibernate에 대해 프로세스 또는 클러스터 범위의 두 번째 레벨 캐시 시스템을 사용하는 것을 허용해준다. 상세한 것은 를 보라. 당신은 hibernate.query.substitutions을 사용하여 새로운 Hibernate 질의 토큰들을 정의할 수 있다. 예를 들어: hibernate.query.substitutions true=1, false=0 은true와 false 토큰들이 생성된 SQL 내에서 정수 리터럴들로 번역되도록 강제할 것이다. hibernate.query.substitutions toLowercase=LOWER 은 SQL LOWER function 함수 이름을 변경하는 것을 당신에게 허용해 줄 것이다 만일 당신이 hibernate.generate_statistics를 사용 가능하도록 할 경우, Hibernate는 SessionFactory.getStatistics()를 통해 가동 중인 시스템을 튜닝할 때 유용한 많은 통계들을 노출시킬 것이다. Hibernate는 심지어 JMX를 통해 이들 통계들을 노출시키도록 구성될 수 있다. 추가 정보는 org.hibernate.stats에 있는 인터페이스들에 관한 Javadoc를 읽어라. Hibernate는 Apache commons-logging를 사용하여 다양한 이벤트들을 로그시킨다. commons-logging 서비스는 (만일 당신이 classpath 내에 log4j.jar를 포함할 경우) Apache Log4j로 또는 (JDK1.4 이상의 버전에서 실행될 경우) JDK 1.4 로깅으로 직접 출력할 것이다. 당신은 http://jakarta.apache.org에서 Log4j를 다운로드 할 수 있다. Log4j를 사용하기 위해, 당신은 log4j.properties 파일을 당신의 classpath 내에 위치지울 필요가 있을 것이고, 예제 properties 파일은 Hibernate의 src/ 디렉토리 내에 배포되어 있다. 우리는 당신이 Hibernate의 로그 메시지들에 익숙해지기를 강력히 권장한다. 읽기 불가능하지 않게끔 가능한 한 상세하게 Hibernate 로그를 만들도록 많은 작업이 행해졌다. 그것은 본질적인 문제던지기 장치이다. 가장 흥미로운 로그 카테고리들이 다음에 있다: 카테고리 기능 org.hibernate.SQL SQL DML 문장들이 실행될 때 그것들 모두를 로그 시킨다 org.hibernate.type 모든 JDBC 파라미터들을 로그시킨다 org.hibernate.tool.hbm2ddl SQL DDL 문장들이 실행될 때 그것들 모두를 로그 시킨다 org.hibernate.pretty flush 시점에서 세션과 연관된 모든 엔티티들(최대 20개의 엔티티들)의 상태를 로그 시킨다 org.hibernate.cache 모든 second-level 캐시 액티비티를 로그시킨다 org.hibernate.transaction 트랜잭션 관련 액티비티를 로그 시킨다 org.hibernate.jdbc 모든 JDBC 리소스 취득을 로그 시킨다 org.hibernate.hql.ast.AST 질의 파싱 동안에 HQL AST와 SQL AST를 로그시킨다 org.hibernate.secure 모든 JAAS 허가 요청들을 로그시킨다 org.hibernate 모든 것을 로그시킨다(많은 정보이지만, 문제해결에 매우 유용하다) Hibernate로 어플리케이션들을 개발할 때, 당신은 거의 항상 org.hibernate.SQL 카테고리에 대해 이용 가능한 debug 모드로 작업하거나, 다른 방법으로 hibernate.show_sql 프로퍼티를 이용가능하게 하여 작업해야 할 것이다. org.hibernate.cfg.NamingStrategy 인터페이스는 데이터베이스 객체들과 스키마 요소들에 대한 "네이밍 표준"을 지정하는 것을 당신에게 허용해준다. 당신은 Java 식별자들로부터 데이터베이스 식별자들을 자동적으로 생성시키거나 매핑 파일에 주어진 "논리적" 컬럼과 테이블 이름들을 "물리적" 테이블과 컬럼 이름들로 자동적으로 처리하는 규칙들을 제공할 수 있다. 이 특징은 반복되는 잡음(예를 들어 TBL_접두어들)을 제거함으로써, 매핑 문서의 말많은 장황함을 감소시키도록 도와준다. Hibernate에 의해 사용되는 디폴트 방도는 아주 작은 작품이다. 당신은 매핑들을 추가하기 이전에 Configuration.setNamingStrategy()를 호출함으로써 다른 방도를 지정할 수 있다: org.hibernate.cfg.ImprovedNamingStrategy는 어떤 어플리케이션들에 대한 유용한 시작점일 수 있는 미리 빌드된 방도이다. 구성에 대한 다른 접근법은 hibernate.cfg.xml로 명명된 파일 속에 전체 구성을 지정하는 것이다. 이 파일은 hibernate.properties 파일에 대한 대용물로서 사용될 수 있거나, 만일 둘 다 존재할 경우에 프로퍼티들을 중복정의하는데 사용될 수 있다. XML 구성 파일은 디폴트로 당신의 CLASSPATH의 루트에 존재하는 것이 기대된다. 다음은 예제이다: java:/comp/env/jdbc/MyDB org.hibernate.dialect.MySQLDialect false org.hibernate.transaction.JTATransactionFactory java:comp/UserTransaction ]]> 당신이 볼 수 있듯이, 이 접근법의 장점은 구성에 대한 매핑 파일 이름들을 구체화 시키는 것이다. hibernate.cfg.xml은 또한 당신이 Hibernate 캐시를 튜닝해야할 때 보다 편리하다. hibernate.properties 또는 hibernate.cfg.xml 중 어느 것을 사용하는가는 당신의 선택이다. XML 구문을 사용하는 위에 언급된 이점들을 제외하면 둘다 같은 것임을 노트하라. Hibernate 구성으로, Hibernate를 시작하는 것은 다음과 같이 간단하다 당신은 다음을 사용하여 다른 XML 구성 파일을 찾아낼 수 있다 Hibernate는 J2EE 인프라스트럭처에 대한 다음 통합 점들을 갖고 있다: Container-managed datasources: Hibernate는 컨테이너에 의해 관리되는 JDBC 커넥션들을 사용할 수 있고 JNDI를 통해 제공된다. 대개 JTA 호환 TransactionManager와 ResourceManager는 트랜잭션 관리(CMT), 특히 몇몇 데이터소스들을 가로질러 분산된 트랜잭션 핸들링을 처리한다. 물론 당신은 또한 프로그램 상으로 트랜잭션 경계들을 한정할 수도 있거나(BMT) 당신은 당신의 코드가 이식성을 유지하도록 이것에 대한 선택적인 Hibernate Transaction API를 사용하고자 원할 수도 있다. 자동적인 JNDI 바인딩: Hibernate는 시작 후에 그것의 SessionFactory를 JNDI에 바인드 시킬 수 있다. JTA Session 바인딩: Hibernate Session은 당신이 EJB들을 사용하고자 원할 경우에 JTA 트랜잭션들의 영역(scope)에 자동적으로 바인드 시킬 수도 있다. 간단하게 JNDI로부터 SessionFactory를 룩업하고 현재 Session을 얻어라. Hibernate로 하여금 당신의 JTA 트랜잭션이 완료될 때 Session을 flush시키고 닫는 것을 처리하도록 하라. 트랜잭션 경계 설정은 EJB 배치 디스크립터들 내에서 선언적이다. JMX 배치: 만일 당신이 JMX 가용성이 있는 어플리케이션 서버(예를 들면 JBoss AS)를 갖고 있다면, 당신은 Hibernate를 하나의 managed MBean으로서 배치하는 것을 선택할 수 있다. 이것은 Configuration으로부터 당신의 SessionFactory를 빌드 시키는 한 줄의 시작 코드를 절약해준다. 컨테이너는 당신의 HibernateService를 시작할 것이고, 또한 이상적으로 서비스 의존성들을 처리할 것이다(데이터소스는 Hibernate가 시작되기 전에 이용 가능해야 한다). 당신의 환경에 따라, 당신은 당신의 어플리케이션 서버가 "connection containment(연결 봉쇄)" 예외상황들을 보일 경우에 구성 옵션 hibernate.connection.aggressive_release를 true로 설정해야 될 수도 있다. Hibernate Session API는 당신의 아카텍처 내에서 임의의 트랜잭션 관할 시스템에 독립적이다. 만일 당신이 Hibernate로 하여금 커넥션 풀을 통해 직접 JDBC를 사용하도록 강제할 경우, 당신은 JDBC API를 호출하여 당신의 트랜잭션을 시작하고 끝낼 수 있다. 만일 당신이 J2EE 어플리케이션 서버를 실행 중이라면, 당신은 필요할 때 bean-managed 트랜잭션들을 사용하고 JTA API와 UserTransaction을 호출하고자 원할 수 있다. 이들 두 개의 (그리고 다른) 환경들에서 당신의 코드에 이식성을 유지하기 위해 우리는 기본 시스템을 포장하고 은폐시키는 선택적인 Hibernate Transaction API를 권장한다. 당신은 Hibernate 구성 프로퍼티 hibernate.transaction.factory_class를 사용하여 Transaction 인스턴스들에 대한 팩토리 클래스를 지정해야 한다. 세 개의 표준(미리 만들어진) 선택들이 존재한다: org.hibernate.transaction.JDBCTransactionFactory 데이터베이스 (JDBC) 트랜잭션들에게 위임시킨다(디폴트) org.hibernate.transaction.JTATransactionFactory 기존의 트랜잭션이 이 컨텍스트(예를 들면 EJB session bean 메소드) 내에서 진행 중일 경우에 container-managed transaction에게 위임시키고, 그 밖의 경우 새로운 트랜잭션이 시작되고 bean-managed transaction이 사용된다. org.hibernate.transaction.CMTTransactionFactory container-managed JTA 트랜잭션들에게 위임시킨다 당신은 또한 당신 자신의 트랜잭션 방도들(예를 들면 CORBA 트랜잭션 서비스)을 정의할 수도 있다. Hibernate에 있는 몇몇 특징들(예를 들면. second level 캐시, 자동적인 JTA 및 Session 바인딩, 기타)은 관리되는 환경에서 JTA TransactionManager에 대한 접근을 필요로 한다. 어플리케이션 서버에서 당신은 Hibernate가 TransactionManager에 대한 참조를 획득하는 방법을 지정해야 한다. 왜냐하면 J2EE가 한 개의 메커니즘을 표준화 시키고 있지 않기 때문이다: 트랜잭션 팩토리 어플리케이션 서버 org.hibernate.transaction.JBossTransactionManagerLookup JBoss org.hibernate.transaction.WeblogicTransactionManagerLookup Weblogic org.hibernate.transaction.WebSphereTransactionManagerLookup WebSphere org.hibernate.transaction.WebSphereExtendedJTATransactionLookup WebSphere 6 org.hibernate.transaction.OrionTransactionManagerLookup Orion org.hibernate.transaction.ResinTransactionManagerLookup Resin org.hibernate.transaction.JOTMTransactionManagerLookup JOTM org.hibernate.transaction.JOnASTransactionManagerLookup JOnAS org.hibernate.transaction.JRun4TransactionManagerLookup JRun4 org.hibernate.transaction.BESTransactionManagerLookup Borland ES 하나의 JNDI 바인드된 Hibernate SessionFactory는 그 팩토리에 대한 룩업과 새로운 Session들의 생성을 단순화 시킬 수 있다. 이것은 JNDI 바인드된 Datasource에 관련되어 있지 않고, 단순하게 둘 다 동일한 레지스트리를 사용한다는 점을 노트하라! 만일 당신이 SessionFactory를 하나의 JNDI namespace에 바인드 시키고자 원할 경우, hibernate.session_factory_name 프로퍼티를 사용하여 한 개의 이름(예를 들면. java:hibernate/SessionFactory)을 지정하라. 만일 이 프로퍼티가 생략될 경우, SessionFactory는 JNDI에 바인드 되지 않을 것이다. (이것은 읽기-전용 JNDI 디폴트 구현을 가진 환경들, 예를 들면 Tomcat에서 특히 유용하다.) SessionFactory를 JNDI에 바인드 시킬 때, Hibernate는 초기 컨텍스트를 초기화 시키기 위해 hibernate.jndi.url, hibernate.jndi.class의 값들을 사용할 것이다. 만일 그것들이 지정되어 있지 않을 경우, 디폴트 InitialContext가 사용될 것이다. Hibernate는 당신이 cfg.buildSessionFactory()를 호출한 후에 SessionFactory를 JNDI 내에 자동적으로 위치지울 것이다. 이것은 당신이 (나중에 논의되는) HibernateService를 가진 JMX 배치를 사용하지 않는 한, 당신이 적어도 당신의 어플리케이션 내에 있는 어떤 시작 코드 (또는 유틸리티 클래스) 내에서 이것을 호출할 것임을 의미한다. 만일 당신이 하나의 JNDI SessionFactory를 사용할 경우, 하나의 EJB 또는 어떤 다른 클래스는 JNDI 룩업을 사용하여 SessionFactory를 얻을 수 있다. 만일 당신이 제 1장에서 소개된 하나의 Singleton 레지스트리로서 행동하는 HibernateUtil helper 클래스를 사용할 경우 이 셋업이 필수적이지 않음을 노트하라. 하지만 HibernateUtil은 관리되지 않는 환경에서 보다 공통적이다. 관리되지 않는 환경들에서 우리는 static SessionFactory를 가진 HibernateUtil, 그리고 Hibernate Session에 대한 ThreadLocal 관리를 제안했다. 몇몇 EJB들이 동일 트랜잭션 내에서 실행되지만 동일 쓰레드 내에서 실행되지 않을 수 있으므로, 이 접근법은 EJB 환경에서 사용하기가 쉽지 않다. 우리는 당신이 관리되는 환경에서 SessionFactory를 JNDI에 바인드 시키는 것을 권장한다. 당신 자신의 ThreadLocal 유틸리티를 조작하는 대신, Hibernate Session을 얻는데 SessionFactory 상의 getCurrentSession() 메소드를 사용하라. 만일 현재의 JTA 트랜잭션 내에 Hibernate Session이 존재하지 않을 경우, 세션이 시작되고 할당될 것이다. hibernate.transaction.flush_before_completion과 hibernate.transaction.auto_close_session 구성 옵션 둘 다 당신이 getCurrentSession()으로 검색하는 모든 Session에 대해 자동적으로 설정될 것이고, 따라서 세션들은 또한 컨테이너가 JTA 트랜잭션들을 끝낼 때 자동적으로 flush되고 닫혀질 것이다. 예를 들어 만일 당신이 당신의 영속 계층을 작성하는데 DAO 디자인 패턴을 사용할 경우, 모든 DAO는 필요할 때 SessionFactory를 룩업하고 "현재(current)" Session을 연다. 제어 코드와 DAO 코드 사이에서 SessionFactory 또는 Session의 인스턴스들을 전달할 필요가 없다. cfg.buildSessionFactory() 줄은 여전히 JNDI에 붙은 하나의 SessionFactory를 얻기 위해 어딘가에서 실행되어야 한다. 당신은 (HibernateUtil 내에 있는 것처럼) static initializer 블록 속에서 이것을 행할 수 있거나 당신은 Hibernate를 managed service로서 배치할 수 있다. Hibernate는 JBoss AS와 같은 JMX 가용성들을 가진 어플리케이션 서버 상의 배치를 위해 org.hibernate.jmx.HibernateService를 배포하고 있다. 실제 배치와 구성은 벤더 지정적이다. 다음은 JBoss 4.0.x를 위한 jboss-service.xml 예제이다: jboss.jca:service=RARDeployer jboss.jca:service=LocalTxCM,name=HsqlDS java:/hibernate/SessionFactory java:HsqlDS org.hibernate.dialect.HSQLDialect org.hibernate.transaction.JTATransactionFactory org.hibernate.transaction.JBossTransactionManagerLookup true true 5 true org.hibernate.cache.EhCacheProvider true true auction/Item.hbm.xml,auction/Category.hbm.xml ]]> 이 파일은 META-INF로 명명된 디렉토리 속에 배치되고 확장자 .sar (service archive)를 가진 한 개의 JAR 파일 속에 패키징된다. 당신은 또한 Hibernate, 그것의 필요한 제 3의 라이브러리들, 당신의 컴파일된 영속 클래스들 뿐만 아니라 당신의 매핑 파일들을 동일한 아카이브 속에 패키징할 필요가 있다. 당신의 엔터프라이즈 빈즈(대개 session beans)는 그것들 자신의 JAR 파일 속에 유지될 수 있지만, 당신은 한 개의 (hot-)배치 가능한 단위를 얻기 위해 메인 서비스 아카이브 속에 이 EJB JAR 파일을 포함시킬 수도 있다. JMX 서비스와 EJB 배치에 관한 추가 정보는 JBoss AS 문서를 참조하라.