이 튜토리얼은 웹 기반의 어플리케이션 용 Apache Tomcat 서블릿 컨테이너에 대한 Hibernate 3.0 셋업을 설명한다(우리는 버전 4.1을 사용했다. 5.0에 대한 차이점들은 적을 것이다). Hibernate는 모든 주요 J2EE 어플리케이션 서버들의 관리되는 환경에서 잘 동작하고, 또는 심지어 스탠드얼론 어플리케이션들에서도 잘 동작한다. 이 튜토리얼에 사용되는 데이터베이스 시스템은  PostgreSQL 7.4이고, 다른 데이터베이스에 대한 지원은  단지 Hibernate SQL dialect 구성과 커넥션 프로퍼티들을 변경시키는 것에만 관계된다. 

먼저 우리는 모든 필수적인 라이브러리들을 Tomcat 설치 장소에 복사해야 한다. 우리는 이 튜토리얼을 위해 별도의 웹 컨텍스트(webapps/quickstart)를 사용하며, 따라서 우리는 전역 라이브러리 검색 경로(TOMCAT/common/lib)와  webapps/quickstart/WEB-INF/lib(JAR 파일들의 경우)와 webapps/quickstart/WEB-INF/classes 내 에 있는 컨텍스트 레벨에서 클래스로더 양자를 고려해야 한다. 우리는 두 개의 클래스로더 레벨들을 전역 classpath와 컨텍스트 classpath로 언급한다.

이제 라이브러리들을 두 개의 classpath들에 복사하라: 

우리는 이제 Tomcat과 Hibernate 양자에서 데이터베이스 풀링과 공유를 설정한다. 이것은 Tomcat이 (그것의 빌드되어 있는 DBCP 풀링 특징을 사용하여) 풀링된 JDBC 커넥션들을 제공할 것이고, Hibernate가 JNDI를 통해 이들 커넥션들을 요청한다는 것을 의미한다. 달리 당신은 Hibernate로 하여금 커넥션 풀을 관리하도록 할 수 있다. Tomcat은 그것의 커넥션 풀을 JNDI에 바인드 시킨다; 우리는 리소스 선언을 Tomcat 메인 구성 파일 TOMCAT/conf/server.xml에 추가한다: 

<Context path="/quickstart" docBase="quickstart">
    <Resource name="jdbc/quickstart" scope="Shareable" type="javax.sql.DataSource"/>
    <ResourceParams name="jdbc/quickstart">
        <parameter>
            <name>factory</name>
            <value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
        </parameter>

        <!-- DBCP database connection settings -->
        <parameter>
            <name>url</name>
            <value>jdbc:postgresql://localhost/quickstart</value>
        </parameter>
        <parameter>
            <name>driverClassName</name><value>org.postgresql.Driver</value>
        </parameter>
        <parameter>
            <name>username</name>
            <value>quickstart</value>
        </parameter>
        <parameter>
            <name>password</name>
            <value>secret</value>
        </parameter>

        <!-- DBCP connection pooling options -->
        <parameter>
            <name>maxWait</name>
            <value>3000</value>
        </parameter>
        <parameter>
            <name>maxIdle</name>
            <value>100</value>
        </parameter>
        <parameter>
            <name>maxActive</name>
            <value>10</value>
        </parameter>
    </ResourceParams>
</Context>

우리가 이 예제에서 구성하는 컨텍스트는 quickstart로 명명되고, 그것의 베이스는 TOMCAT/webapp/quickstart 디렉토리이다. 임의의 서블릿들에 접근하기 위해, (물론 당신의 web.xml 속에 매핑된 서블릿의 이름을 추가하여) 당신의 브라우저에서 http://localhost:8080/quickstart 경로를 호출하라. 당신은 또한 계속 진행하고 이제 공백의 process() 메소드를 가진 간단한 서블릿을 생성시킬 수 있다. 

Tomcat은 이제 java:comp/env/jdbc/quickstart로 JNDI을 통해 커넥션들을 제공한다. 만일 당신이 실행 중인 커넥션 풀을 얻는 것에 문제가 있다면 Tomcat 문서를 참조하라. 당신이 JDBC 드라이버 예외상황 메시지를 얻을 경우, 먼저 Hibernate 없이 JDBC 커넥션 풀을 셋업하라. Tomcat & JDBC 튜토리얼들은 그 웹 서이트에서 이용 가능하다.

당신의 다음 단계는 Hibernate를 구성하는 것이다. Hibernate는 그것이 JDBC 커넥션들을 얻는 방법을 알고 있어야 한다. 우리는 Hibernate의 XML 기반 구성을 사용한다.  properties 파일을 사용하는 다른 접근법은 거의 동일하지만 XML 구문이 허용하는 몇몇 특징들을 누락하고 있다.  XML 구성 파일은 hibernate.cfg.xml로서 컨텍스트 classpath (WEB-INF/classes) 내에  위치해 있다:

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-configuration PUBLIC
    "-//Hibernate/Hibernate Configuration DTD//EN"
    "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">

<hibernate-configuration>

    <session-factory>

        <property name="connection.datasource">java:comp/env/jdbc/quickstart</property>
        <property name="show_sql">false</property>
        <property name="dialect">org.hibernate.dialect.PostgreSQLDialect</property>

        <!-- Mapping files -->
        <mapping resource="Cat.hbm.xml"/>

    </session-factory>

</hibernate-configuration>

우리는 SQL 명령들에 대한 로깅을 사용하지 않고 Hibernate에게 사용되는 데이터베이스 SQL direct가 무엇인지 그리고 (Tomcat 바인드된 풀의 JNDI 주소를 선언하여) JDBC 커넥션들을 얻는 곳을 알려준다. dialect는 필수적인 설정이고, 데이터베이스들은 SQL "표준"에 대한 그것들의 해석을 달리한다. Hibernate는 차이점들을 처리하고 모든 주요 상용 데이터베이스들 및 오픈 소스 데이터베이스들 용도의 direct들을 번들로 포함하고 있다.

SessionFactory 는 단일 데이터저장소에 관한 개념이고, 여러 데이터베이스들은 여러 개의 XML 구성 파일들을 생성시키고 당신의 어플리케이션 속에서 여러 개의 Configuration 및 SessionFactory 객체들을 생성시켜서 사용될 수 있다.

hibernate.cfg.xml의 마지막 요소는 영속 클래스 Cat에 대한 Hibernate XML 매핑 파일의 이름으로써 Cat.hbm.xml을 선언한다. 이 파일은 데이터베이스 테이블(또는 테이블들)로 POJO 클래스 Cat 을 매핑시키는 메타데이터를 포함한다. 우리는 곧 그 파일로 되돌아 갈 것이다. 먼저 POJO 클래스를 작성하고 그런 다음 그것을 위한 매핑 메타데이터를 선언하자.

Hibernate는 영속 클래스들에 대한 Plain Old Java Objects (POJOs, 종종 Plain Ordinary Java Objects로 명명된다) 프로그래밍 모형으로 가장 잘 동작한다.  POJO는 공용으로 가시적인 인터페이스로부터 내부적인 표상을 은폐시켜, getter와 setter 메소드들을 통해 접근가능한 클래스들의 프로퍼티들을 가진 자바빈과 꽤 유사하다(필요하다면 Hibernate는 또한 필드들에 직접 접근할 수 있다):

package org.hibernate.examples.quickstart;

public class Cat {

    private String id;
    private String name;
    private char sex;
    private float weight;

    public Cat() {
    }

    public String getId() {
        return id;
    }

    private void setId(String id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public char getSex() {
        return sex;
    }

    public void setSex(char sex) {
        this.sex = sex;
    }

    public float getWeight() {
        return weight;
    }

    public void setWeight(float weight) {
        this.weight = weight;
    }

}

Hibernate는 그것의 프로퍼티 타입들의 사용에 제약되지 않고, 자바 콜렉션 프레임웍에서의 클래스들을 포함하여, 모든 자바 JDK 타입들과 (String, char와 Date 같은) 원시타입들이 매핑될 수 있다. 당신은 그것을 값들로서, 값들을 가진 콜렉션들로서, 또는 다른 엔티티들에 대한 연관들로서 매핑시킬 수 있다.  id 는 그 클래스의 데이터베이스 식별자(프라이머리 키)를 표현하는 특별한 프로퍼티이고, 그것은 Cat과 같은 엔티티들에 대해 매우 권장된다. Hibernate는 내부적으로만 식별자들을 사용할 수 있지만, 우리는 우리의 어플리케이션 아키텍처에서 어떤 유연성을 상실하게 될 것이다. 

특정 인터페이스는 영속 클래스들에 대해 구현되지 말아야 하거나 특정 루트 영속 클래스로부터 서브 클래스로 만들지 말아야 한다. Hibernate는 또한 바이트 코드 처리와 같은, 어떤 빌드 시 처리를 필요로 하지 않고, 그것은 오직 자바 reflection과 (CGLIB를 통한) 런타임 클래스 고양에만 의존한다. 따라서 Hibernate에 대한 POJO 클래스의 어떤 의존성 없이도, 우리는 그것을 데이터베이스 테이블로 매핑할 수 있다.

Cat.hbm.xml 매핑파일은 객체/관계형 매핑에 필요한 메타데이터를 포함한다. 메타데이터는 영속 클래스들의 선언과 데이터베이스 테이블들에 대한 (컬럼들과 다른 엔티티들에 대한 foreign 키 관계들에 대한) 프로퍼티들의 매핑을 포함한다.

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
    "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
    "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping>

    <class name="org.hibernate.examples.quickstart.Cat" table="CAT">

        <!-- A 32 hex character is our surrogate key. It's automatically
            generated by Hibernate with the UUID pattern. -->
        <id name="id" type="string" unsaved-value="null" >
            <column name="CAT_ID" sql-type="char(32)" not-null="true"/>
            <generator class="uuid.hex"/>
        </id>

        <!-- A cat has to have a name, but it shouldn' be too long. -->
        <property name="name">
            <column name="NAME" length="16" not-null="true"/>
        </property>

        <property name="sex"/>

        <property name="weight"/>

    </class>

</hibernate-mapping>

모든 영속 클래스는 식별자 속성을 가져야 한다(실제로 value-타입의 클래스들에 의존하지 않는, 엔티티들을 표현하는 유일한 클래스들은 엔티티을 가진 컴포넌트들로 매핑된다). 이 프로퍼티는 영속 객체들을 구별짓는데 사용된다: 만일 catA.getId().equals(catB.getId())이 true일 경우, 두 개의 cat들은 같고, 이 개념은 database identity로 명명된다.  Hibernate는 (데이터베이스 시퀀스, hi/lo 식별자 테이블들, 그리고 어플리케이션 할당 식별자들에 대한 native 생성기들을 포함하는) 다른 시나리오들에 대해 여러 가지 식별자 생성기들을 번들로 갖고 있다. 우리는 UUID 생성기(데이터이스에 의해 생성된 정수 대용 키들이 선호될 것이므로, 테스트용으로만 권장됨)를 사용하고 또한  Hibernate 생성된 식별자 값을 위한 CAT 테이블의 CAT_ID 컬럼을 (테이블의 프라이머리 키로서) 지정한다. 

Cat 의 모든 다른 프로퍼티들은 동일한 테이블로 매핑된다. name 프로퍼티의 경우에, 우리는 그것을 명시적인 데이터베이스 컬럼 선언으로 매핑시켰다. 데이터베이스 스키마가 Hibernate의 SchemaExport  도구에 의해 매핑 선언으로부터 (SQL DDL 문장들로) 자동적으로 생성될 때 이것이 특별히 유용하다. 모든 다른 프로퍼티들은 Hibernate의 디폴트 설정들을 사용하여 매핑되고, 디폴트 설정들은 당신이 가장 많은 시간을 필요로 하는 것이다. 데이터베이스 내의 테이블 CAT 은 다음과 같다:

 Column |         Type          | Modifiers
--------+-----------------------+-----------
 cat_id | character(32)         | not null
 name   | character varying(16) | not null
 sex    | character(1)          |
 weight | real                  |
Indexes: cat_pkey primary key btree (cat_id)

당신은 이제 수작업으로 당신의 데이터베이스 내에 이 테이블을 생성시킬 것이고, 만일 당신이 hbm2ddl 도구로 이 단계를 자동화 시키고자 원할 경우 20 장, 도구셋 안내를 읽어라. 이 도구는 테이블 정의, 맞춤형 컬럼 타입 컨스트레인트들, 유일 컨스트레인트들과 인덱스들을 포함하는, 전체 SQL DDL을 생성시킬 수 있다.

우리는 이제 Hibernate의 Session을 시작할 준비가 되어 있다. 그것은  persistence manager(영속 관리자)이고, 우리는 데이터베이스로 Cat를 저장하고 데이터베이스로부터 Cat를 검색하는데 그것을 사용한다. 그러나 먼저 우리는 SessionFactory로부터 Session (Hibernate의 작업 단위)를 얻어야 한다:

SessionFactory sessionFactory =
            new Configuration().configure().buildSessionFactory();

configure() 호출은 hibernate.cfg.xml 구성 파일을 로드시키고  Configuration  인스턴스를 초기화 시킨다. 당신이 SessionFactory(불변적임)를 빌드하기 이전에 당신은 Configuration에 접근함으로써 다른 프로퍼티들을 설정할 수 있다(그리고 심지어 매핑 메타데이터를 변경시킬 수 있다). 우리는 어디서 SessionFactory를 생성시키고 우리의 어플리케이션 속에서 어떻게 그것에 접근할 수 있나?

SessionFactory 는 대개 오직 한번만, 예를 들어 대개 load-on-startup 서블릿으로 시작 시에 빌드된다. 이것은 또한 당신이 당신의 서블릿들 내에 있는 인스턴스 변수 속에 그것을 유지하지 않을 것이지만 어떤 다른 위치에 유지시킬 것임을 의미한다. 더구나 우리는 어떤 종류의 Singleton을 필요로 하며, 따라서 우리는 어플리케이션 코드로 쉽게 SessionFactory 에 액세스 할 수 있다.  다음에 보여진 접근법은 두 문제 모두를 해결한다: 시작 구성과 SessionFactory에 대한 쉬운 접근.

우리는 HibernateUtil helper 클래스를 구현한다:

import org.hibernate.*;
import org.hibernate.cfg.*;

public class HibernateUtil {

    private static Log log = LogFactory.getLog(HibernateUtil.class);

    private static final SessionFactory sessionFactory;

    static {
        try {
            // Create the SessionFactory
            sessionFactory = new Configuration().configure().buildSessionFactory();
        } catch (Throwable ex) {
            // Make sure you log the exception, as it might be swallowed
            log.error("Initial SessionFactory creation failed.", ex);
            throw new ExceptionInInitializerError(ex);
        }
    }

    public static final ThreadLocal session = new ThreadLocal();

    public static Session currentSession() {
        Session s = (Session) session.get();
        // Open a new Session, if this Thread has none yet
        if (s == null) {
            s = sessionFactory.openSession();
            session.set(s);
        }
        return s;
    }

    public static void closeSession() {
        Session s = (Session) session.get();
        if (s != null)
            s.close();
        session.set(null);
    }
}

이 클래스는 static 초기자를 가진 SessionFactory를 처리할 뿐만 아니라 또한 현재의 쓰레드를 위한 Session 을 보관하는 ThreadLocal변수를 갖는다. 이 helper를 사용하려고 시도하기 전에 thread-local 변수에 대한 자바 개념을 이해해야 한다. 보다 복잡하고 강력한 HibernateUtil 클래스는  http://caveatemptor.hibernate.org/의 CaveatEmptor에서 찾을 수 있다.

 SessionFactory는 threadsafe이고, 많은 쓰레드들이 동시에 그것에 접근할 수 있고 Session들을 요청할 수 있다. 하나의 Session은 데이터베이스에 대해 한 개의 단위 작업을 나타내는 non-threadsafe 객체이다.  Session들은 SessionFactory로부터 열려지고 모든 작업이 완료될 때 닫혀진다. 당신의 서블릿의 process() 메소드 내에 있는 예제는 다음과 같을 수 있다(예외상황 처리 없이): 

Session session = HibernateUtil.currentSession();
Transaction tx = session.beginTransaction();

Cat princess = new Cat();
princess.setName("Princess");
princess.setSex('F');
princess.setWeight(7.4f);

session.save(princess);

tx.commit();
HibernateUtil.closeSession();

하나의 Session 내에서 모든 데이터베이스 오퍼레이션은 데이터베이스 오퍼레이션들(심지어 읽기 전용 오퍼레이션들 조차도)을 격리시키는 하나의 트랜잭션 내부에서 발생한다. 우리는 기본 트랜잭션 방도(우리의 경우, JDBC 틀내잭션들)로부터 추상화시키는데 Hibernates Transaction API 를 사용한다. 이것은 우리의 코드가 임의의 변경들 없이도 (JTA를 사용하는) 컨테이너-관리되는 트랜잭션들에 배치되는 것을 허용해준다.

당신이 원하는 만큼 당신이 HibernateUtil.currentSession();을 호출할 수 있고, 당신은 이 쓰레드의 현재 Session을 항상 얻을 것임을 노트하라. 당신은 서블릿 코드 내에서든 또는 서블릿 필터 내에서든 HTTP response가 전송되기 전에, 당신의 단위 작업이 완료된 후에 Session을 확실히 닫아야 한다.  두 번째 옵션의 좋은 측면은 쉬운 lazy 초기화이다: 뷰가 렌더링 될 때 Session이 여전히 열려져 있어서,  Hibernate는 당신이 현재 객체 그래프를 네비게이트 하는 동안 초기화 되지 않은 객체들을 로드시킬 수 있다. 

Hibernate는 데이터베이스로부터 객체들을 검색하는데 사용될 수 있는 다양한 메소드들을 갖고 있다. 가장 유연한 방법은 Hibernate Query Language (HQL)을 사용하는 것이다. Hibernate Query Language (HQL)은 배우기가 쉽고 SQL에 대한 강력한 객체 지향 확장이다:

Transaction tx = session.beginTransaction();

Query query = session.createQuery("select c from Cat as c where c.sex = :sex");
query.setCharacter("sex", 'F');
for (Iterator it = query.iterate(); it.hasNext();) {
    Cat cat = (Cat) it.next();
    out.println("Female Cat: " + cat.getName() );
}

tx.commit();

Hibernate는 또한 type-safe 질의들을 공식화 시키는데 사용될 수 있는 객체 지향 query by criteria API을 제공한다. 물론 Hibernate는 데이터베이스와의 모든 SQL 통신을 위해 PreparedStatement들과 파라미터 바인딩을 사용한다. 당신은 또한 Hibernate 직접적인 SQL 질의 특징을 사용할 수도 있거나 드문 경우에 Session 로부터 plain JDBC 커넥션을 얻을 수도 있다.

우리는 이 작은 튜토리얼 내에서 단지 Hibernate의 표면을 훑기만 했다. 우리는 우리의 예제들 속에 어떤 서블릿 지정적 코드를 포함하지 않음을 노트하라. 당신이 적합한지를 알려고 할 때 당신은 당신 자신의 서블릿을 생성시켜야 하고 Hibernate 코드를 삽입해야 한다. 

데이터 접근 계층으로서 Hibernate는 당신의 어플리케이션에 강하게 통합됨을 염두에 두라. 대개 모든 다른 레이어들은 영속 메커니즘에 의존했다. 당신은 이 설계의 함축을 확실히 이해하도록 하라.

보다 복잡한 어플리케이션 예제는 http://caveatemptor.hibernate.org/ 를 보고 http://caveatemptor.hibernate.org/에 있는 다른 튜토리얼들을 살펴보라.

Hibernate 아키텍처에 대한 (매우) 높은 수준의 개요: 

이 다이어그램은 어플리케이션에 영속화 서비스들(과 영속 객체들)을 제공하기 위해 데이터베이스와 컨피그레이션을 사용하는 Hibernate를 보여준다.

우리는 런타임 아키텍처에 대한 보다 상세한 뷰를 보여주고 싶다. 불행하게도, Hibernate는 유연하며 몇 가지 접근법들을 제공한다. 우리는 두 가지 극단을 보여줄 것이다. "경량급" 아키텍처는 그것 자신의 JDBC 커넥션들을 제공하고 그것 자신의 트랜잭션들을 관리하는 어플리케이션을 갖는다. 이 접근법은 Hibernate의 API의 최소 부분집합을 사용한다:

"전체 정수" 아키텍처는 기본 JDBC/JTA로부터 어플리케이션을 추상화 시키고 Hibernate로 하여금 상세한 것을 처리하게 한다.

다음은 다이어그램들 내에 있는 객체들에 대한 몇가지 정의들이다:

주어진 "경량급" 아키텍처의 경우, 어플리케이션은 JTA 또는 JDBC와 직접 대화하기 위해서 Transaction/TransactionFactory 과/또는 ConnectionProvider API들을 무시한다.

영속 클래스들의 인스턴스는 세개의 상태들 중 하나 일 수 있다. 그것들(상태들)은 영속  컨텍스트(persistence context)에 대해 정의된다. Hibernate Session 객체는 영속 컨텍스트이다:

JMX는 자바 컴포넌트 관리를 위한 J2EE 표준이다. Hibernate는 JMX 표준 서비스를 통해 관리될 수도 있다. 우리는 배포본 내에 MBean 구현, org.hibernate.jmx.HibernateService 을 제공한다.

JBoss 어플리케이션 서버 상에 Hibernae를 JMX 서비스로서 배치하는 방법에 대한 예제는 JBoss 사용자 가이드를 보길 바란다. JBoss 어플리케이션 서버 상에서, 만일 당신이 JMX를 사용하여 배치할 경우 당신은 또한 다음 이점들을 얻는다:

Hibernate는 JCA 커넥터로서 구성될 수도 있다. 상세한 것은 웹 사이트를 보길 바란다.

org.hibernate.cfg.Configuration 의 인스턴스는 어플리케이션의 Java 타입들을 SQL 데이터베이스 타입으로의 전체 매핑 집합을 표현한다. Configuration 은 (불변의) SessionFactory를 빌드하는데 사용된다. 매핑들은 여러 가지 XML 매핑 파일들로부터 컴파일 된다.

당신은 Configuration 인스턴스를 초기화 함으로써 Configuration 인스턴스를 얻을 수 있다. 다음은 (classpath 내에 있는) 두 개의 XML 매핑 파일 속에 정의된 매핑들로부터 데이터저장소를 설정하는 예제이다:

Configuration cfg = new Configuration()
    .addFile("Item.hbm.xml")
    .addFile("Bid.hbm.xml");

(때때로 더 나은) 다른 방법은 getResourceAsStream()을 사용하여 Hibernate로 하여금 매핑 파일을 로드시키도록 하는 것이다:

Configuration cfg = new Configuration()
    .addClass(org.hibernate.auction.Item.class)
    .addClass(org.hibernate.auction.Bid.class);

그런 다음 Hibernate는 classpath 내에 /org/hibernate/auction/Item.hbm.xml 과 /org/hibernate/auction/Bid.hbm.xml로 명명된 매핑 파일들을 룩업할 것이다. 이 접근법은 임의의 하드코딩된 파일 이름들을 제거한다. 

Configuration 은 또한 다양한 옵션 프로퍼티들을 지정한다: 

Configuration cfg = new Configuration()
    .addClass(org.hibernate.auction.Item.class)
    .addClass(org.hibernate.auction.Bid.class)
    .setProperty("hibernate.dialect", "org.hibernate.dialect.MySQLInnoDBDialect")
    .setProperty("hibernate.connection.datasource", "java:comp/env/jdbc/test")
    .setProperty("hibernate.order_updates", "true");

이것은 컨피그레이션 프로퍼티들을 Hibernate에 전달하는 유일한 방법이 아니다. 여러 가지 옵션들은 다음을 포함한다:

hibernate.properties 는 당신이 빠르게 시작하고 원할 경우 가장 쉬운 접근법이다. 

Configuration 은 시작 시(startup-time) 객체로서 일단 SessionFactory가 생성되면 폐기되게끔 예정되어 있다. 

모든 매핑들이 Configuration에 의해 파싱되었을 때, 어플리케이션은 Session 인스턴스들에 대한 팩토리를 얻어야 한다. 이 팩토리는 모든 어플리케이션 쓰레드들에 의해 공유되도록 고안되었다: 

SessionFactory sessions = cfg.buildSessionFactory();

하지만 Hibernate는 당신의 어플리케이션이 하나 이상의 SessionFactory를 초기화 시키는 것을 허용한다. 이것은 당신이 하나 이상의 데이터베이스를 사용하는 경우에 유용하다. 

SessionFactory 는 사용자 제공 JDBC 커넥션 상에서 Session 을 열 수 있다. 이 설계 선택은 그것이 만족될 때마다 어플리케이션이 JDBC 커넥션들을 얻는 것을 자유롭게 해준다:

java.sql.Connection conn = datasource.getConnection();
Session session = sessions.openSession(conn);

// 어떤 데이터 액세스 작업을 행한다 

어플리케이션은 동일한 JDBC 커넥션 상에서 두 개의 동시적인 Session들 을 열지 않도록 주의해야 한다!

우리는 사용자 제공 JDBC 커넥션들을 권장하지 않는다. 왜냐하면 Hibernate가 캐싱을 불가능하게 할 것이기 때문이고(그것은 당신이 주어진 커넥션 상에서 실행할 수 있다는 사실을 알지 못한다) 대개 다음 옵션들 중 하나가 더 적절하기 때문이다.

대개 당신은 SessionFactory 를 생성시키고 당신을 위한 JDBC 커넥션들을 풀링시키고자 원한다. 만일 당신이 이 접근법을 취하라 경우, Session을 여는 것은 다음과 같이 간단하다:

Session session = sessions.openSession(); // 새로운 Session을 연다

데이터베이스에 대한 업근을 필요로 하는 어떤 것을 당신이 행하자 마자, JDBC 커넥션이 그 풀로부터 획득될 것이다.

이것이 동작하도록 하기 위해, 우리는몇몇 JDBC 커넥션 프로퍼티들을 Hibernate에 전달할 필요가 있다. 모든 Hibernate 프로퍼티 이름들과 의미들은 org.hibernate.cfg.Environment 클래스 상에 정의되어 있다.우리는 이제 JDBC 커넥션 구성을 위한 가장 중요한 설정들을 설명할 것이다.

당신이 다음 프로퍼티들을 설정할 경우, Hibernate는 java.sql.DriverManager를 사용하여 커넥션들을 획득(그리고 풀링)할 것이다.:

하지만 Hibernate 자신의 커넥션 풀링 알고리즘은 아주 기본적이다. 그것은 당신이 시작하는 것을 도와주려고 의도되었고 제품 시스템 용도 또는 퍼포먼스 테스트용으로 고안되지 않았다. 최상의 퍼포먼스와 안정성을 위해서는 제 3의 풀을 사용하라. 즉 hibernate.connection.pool_size 프로퍼티를 커넥션 풀 지정 설정들로 대체하라. 이것은 Hibernate의 내부 pool을 오프시킬 것이다. 예를 들어 당신은 C3P0를 사용할 수도 있다.

C3P0는 lib 디펙토리 속에 Hibernate에 배포된 오픈 소스 JDBC 커넥션 풀이다. 당신이 hibernate.c3p0.* 프로퍼티들을 설정할 경우  Hibernate는  커넥션 풀링을 위해 그것의 C3P0ConnectionProvider 를 사용할 것이다. 만일 당신이 Proxool 을 사용하고자 원할 경우 패키지화 된 hibernate.properties 를 참조하고 추가 정보는 Hibernate 웹 사이트를 참조하라.

다음은 C3P0에 대한 사용하는 예제 hibernate.properties 파일이다: 

hibernate.connection.driver_class = org.postgresql.Driver
hibernate.connection.url = jdbc:postgresql://localhost/mydatabase
hibernate.connection.username = myuser
hibernate.connection.password = secret
hibernate.c3p0.min_size=5
hibernate.c3p0.max_size=20
hibernate.c3p0.timeout=1800
hibernate.c3p0.max_statements=50
hibernate.dialect = org.hibernate.dialect.PostgreSQLDialect

어플리케이션 서버 내부의 용도로, 당신은 JNDI로 등록된 어플리케이션 서버 Datasource로부터 커넥션을 얻기 위해 항상 Hibernate를 구성해야 한다. 당신은 적어도 다음 프로퍼티들 중 하나를 설정할 필요가 잇을 것이다.

다음은 어플리케이션 서버 제공 JNDI 데이터소스용 예제 hibernate.properties 파일이다:

hibernate.connection.datasource = java:/comp/env/jdbc/test
hibernate.transaction.factory_class = \
    org.hibernate.transaction.JTATransactionFactory
hibernate.transaction.manager_lookup_class = \
    org.hibernate.transaction.JBossTransactionManagerLookup
hibernate.dialect = org.hibernate.dialect.PostgreSQLDialect

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.query.substitutions true=1, false=0

hibernate.query.substitutions toLowercase=LOWER

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 로그를 읽기 불가능하게 만들지 않게끔 가능한 한 상세하게 Hibernate 로그를 집어 넣었다. 그것은 본질적인 문제던지기 장치이다. 가장 흥미로운 로그 카테고리들이 다음에 있다:

Hibernate로 어플리케이션들을 개발할 때, 당신은 거의 항상 org.hibernate.SQL 카테고리에 대해 debug 모드로 설정하거나 hibernate.show_sql 프로퍼티를 이용가능하게 하여 작업해야 할 것이다.

 org.hibernate.cfg.NamingStrategy 인터페이스는 데이터베이스 객체들과 스키마 요소들에 대한 "네이밍 표준"을 지정하는 것을 당신에게 허용해준다.

당신은 Java 식별자들로부터 데이터베이스 식별자들을 자동적으로 생성시키거나 매핑 파일에 주어진 "논리적" 컬럼과 테이블 이름들을 "물리적" 테이블과 컬럼 이름들로 자동적으로 처리하는 규칙들을 제공할 수 있다. 이 특징은 반복되는 노이즈(예를 들어 TBL_접두어들)를 제거함으로써, 매핑 문서의 말많은 장황함을 감소시키도록 도와준다. Hibernate에 의해 사용되는 디폴트 방도는 아주 작은 작품이다.

당신은 매핑들을 추가하기 이전에 Configuration.setNamingStrategy()를 호출함으로써 다른 방도를 지정할 수 있다:

SessionFactory sf = new Configuration()
    .setNamingStrategy(ImprovedNamingStrategy.INSTANCE)
    .addFile("Item.hbm.xml")
    .addFile("Bid.hbm.xml")
    .buildSessionFactory();

org.hibernate.cfg.ImprovedNamingStrategy 는 어떤 어플리케이션들에 대한 유용한 시작점일 수 있는 미리 빌드된 방도이다.

구성에 대한 다른 접근법은 hibernate.cfg.xml로 명명된 파일 속에 전체 구성을 지정하는 것이다. 이 파일은 hibernate.properties 파일에 대한 대용물로서 사용될 수 있거나, 만일 둘 다 존재할 경우에 프로퍼티들을 중복정의하는데 사용될 수 있다.

XML 구성 파일은 디폴트로 당신의 CLASSPATH의 루트에 존재하는 것이 기대된다. 다음은 예제이다:

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-configuration PUBLIC
    "-//Hibernate/Hibernate Configuration DTD//EN"
    "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">

<hibernate-configuration>

    <!-- a SessionFactory instance listed as /jndi/name -->
    <session-factory
        name="java:hibernate/SessionFactory">

        <!-- properties -->
        <property name="connection.datasource">java:/comp/env/jdbc/MyDB</property>
        <property name="dialect">org.hibernate.dialect.MySQLDialect</property>
        <property name="show_sql">false</property>
        <property name="transaction.factory_class">
            org.hibernate.transaction.JTATransactionFactory
        </property>
        <property name="jta.UserTransaction">java:comp/UserTransaction</property>

        <!-- mapping files -->
        <mapping resource="org/hibernate/auction/Item.hbm.xml"/>
        <mapping resource="org/hibernate/auction/Bid.hbm.xml"/>

        <!-- cache settings -->
        <class-cache class="org.hibernate.auction.Item" usage="read-write"/>
        <class-cache class="org.hibernate.auction.Bid" usage="read-only"/>
        <collection-cache class="org.hibernate.auction.Item.bids" usage="read-write"/>

    </session-factory>

</hibernate-configuration>

당신이 볼 수 있듯이, 이 접근법의 장점은 구성에 대한 매핑 파일 이름들을 구체화 시키는 것이다. hibernate.cfg.xml은 또한 당신이 Hibernate 캐시를 튜닝해야할 때 보다 편리하다. hibernate.properties 또는 hibernate.cfg.xml 어느 것을 사용하는가는 당신의 선택이다. XML 구문을 사용하는 위에 언급된 이점들을 제외하면 둘다 같은 것임을 노트하라.

Hibernate 구성을 사용할 경우, Hibernate 사용은 다음과 같이 간단하다

SessionFactory sf = new Configuration().configure().buildSessionFactory();

당신은 다음을 사용하여 다른 XML 구성 파일을 찾아낼 수 있다

SessionFactory sf = new Configuration()
    .configure("catdb.cfg.xml")
    .buildSessionFactory();