Hibernate - Architecture

아래의 그림은 하이버네이트 아키텍처의 고수준의 뷰를 보여준다.

불행하게도 우리는 모든 런타임 아키텍처의 자세한 뷰를 제공할 수 없다. 하이버네이트는 사용하는 방법에 따라 충분히 유연하고, 많은 아키텍처로 나타날 수 있다. 하지만 우리는 특별하게 2가지로 설명을 하겠다.

2.1.1. Minimal architecture

최소한의 아키텍처는 어플리케이션을 가지고 있으며 이 어플리케이션은 자신의 JDBC 연결과 그 연결을 하이버네이트에 제공하는 것을 관리한다. 추가적으로 어플리케이션의 자신을 위한 트랜잭션을 관리한다. 이러한 접근은 Hibernate API에 최소 서브셋을 활용한다.

2.1.2. Comprehensive architecture

포괄적인 아키텍처는 어플리케이션을 JDBC/JTA API와 분리시켜 추상화시키고 하이버네이트는 세부적인 관리를 허용한다.

2.1.3. Basic APIs

이전 다이어그램에서 묘사한 몇몇의 API에 대한 대략적인 설명은 다음과 같다

SessionFactory (org.hibernate.SessionFactory)

하나의 데이터베이스를 위한 컴파일된 매핑의 thread-safe, immutable 캐쉬. Session 인스턴스를 위한 팩토리이며 ConnectionProvider의 클라이언트. 부가적으로 데이터의 세컨드 레벨 캐쉬를 유지한다. 프로세스의 트랜잭션간 혹은 클러스터 레벨에서 재사용될 수 있다.

Session (org.hibernate.Session)

Single-threaded, short-lived 오브젝트이며 퍼시스턴트 스토어와 어플리케이션간의 conversation을 표현한다. JDBC Connection를 래핑한다. Transaction을 위한 팩토리이다. 어플리케이션의 퍼시스턴트 오브젝트와 컬렉션의 퍼스트 레벨 캐쉬를 유지한다. 이 캐쉬는 오브젝트 그래프를 탐색하거나 identifier를 통해 오브젝트를 찾을 때 사용된다.

Persistent objects and collections

Short-lived, single threaded 오브젝트이며  퍼시스턴트 상태와 비즈니스 기능을 포함한다. 일반적인 JavaBean이나 POJO일 수 있다. 직접적으로 Session과 연관된다. Session이 클로즈되면 그들은 어떤 어플리케이션 레이어에서 사용되기 위해 자유롭게 분리 될 것이다. (에를 들어 프리젠테이션을 왔다갔다하는 DTO)

Transient and detached objects and collections

퍼시스턴트 클래스의 인스턴스인데 현재 Session과 연관되어 있지 않은 경우. 어플리케이션으로부터 생성되어 아직 퍼시스턴트 되지 않거나 Session 닫히면서 초기화 되었을때

Transaction (org.hibernate.Transaction)

(Optional) A single-threaded, short-lived 오브젝트이며 어플리케이션에서 하나의 단위작업을 명시할 때 사용된다. 이것은 JDBA, JTA, CORBA 트랜잭션을 추상화한다. Session은 특정한 경우 Transacion에 걸칠 수 있다. 하지만 트랜잭션 경계는 내부적은 트랜잭션 API를 쓰던 하이버네이트의 Transaction을 쓰건 필수이다.

ConnectionProvider (org.hibernate.connection.ConnectionProvider)

(Optional) JDBC 커넥션 풀의 팩토리. 데이터소스나 드라이버매니져를 추상화해서 어플리케이션에 제공한다. 어플리케이션에 노출되지 않지만 개발자에 의해 확장하거나 구현할 수 있다.

TransactionFactory (org.hibernate.TransactionFactory)

(Optional) 트랜잭션 인스턴스들의 팩토리.어플리케이션에 노출되지 않으면 개발자에 의해 확장 또는 구현될 수 있다.

Extension Interfaces

하이버네이트는 확장 인터페이스를 제공한다. 퍼시스턴트 레이어의 동작을 커스터마이징하고 싶다면 이러한 인터페이스들을 구현하면 된다.

2.2. Contextual sessions

하이버네이트를 사용하는 대부분의 어플리케이션에서는 contextual 세션의 몇가지 폼을 필요로한다. 주어진 세션은 주어진 context의 스코프에서 영향을 받는다. 하지만 어플리케이션을 넘어 컨텍스트를 구성하는 정의는 일반적으로 다르다. 다른 컨텍스트는 현재의 표시를 다른 스코프를 정의한다. 하이버네이트 3.0전 버젼의 어플리케이션들은 자가생산된 ThreadLocal 기반의 컨텍스트 세션을 이용하였다. HibernateUtil 또는 Spring 또는 Pico와 같은  서드 파티 프레임워크의 헬퍼크래스들이 그러했다.

하이버네이트 3.0.1부터 SessionFactory.getCurrentSession() 메소드가 추가 되었다. 처음에는 JTA 트랜잭션를 사용할 것으로 가정하였다. 여기서 JTA 트랜잭션은 현재 세션의 context와 scope가 모두 정의되었을 것이라 생각했다. 수많은 stand-alone JRA 트랜잭션매니져 구현체의 대부분은 어플리케이션들은 전부가 아니더라도 JTA 트랜잭션 관리를 사용할 것이라고 생각했다. J2EE 컨테이너에 배포되던지 아니던지 간에 이에 기초해 JTA기반 contextual session을 원한다면 사용할 수 있다.

하지만 버전 3.1 이후로 SessionFactory.getCurrentSession() 이면의 처리과정은 이제 플러그 가능하다. 그것을 끝내기 위해, 하나의 새로운 확장 인터페이스 (org.hibernate.context.CurrentSessionContext)와 하나의 새로운 구성 파라미터(hibernate.current_session_context_class)가 현재 세션들을 정의하는 영역과 컨텍스트의 플러그 가능성을 허용하기 위해 추가되었다.

그것의 계약에 대한 상세한 논의는 org.hibernate.context.CurrentSessionContext 인터페이스에 관한 javadocs를 보라. 그것은 하나의 메소드, currentSession()를 정의하며, 그 구현은 현재의 컨텍스트 상의 세션을 추적할 책임이 있다. 비공식적으로, Hibernate는 이 인터페이스에 대한 구 개의 구현들을 부수적으로 포함하고 있다.

• org.hibernate.context.JTASessionContext - 현재의 세션들은 하나의 JTA에 의해 추적되고 영역화 된다. 여기서 처리과정은 이전의 JTA-전용 접근과 정확하게 동일하다. 상세한 것은 javadocs를 보라.
• org.hibernate.context.ThreadLocalSessionContext - 현재의 세션들은 실행 쓰레드에 의해 추적된다. 상세한 것은 다시 javadocs를 보라.

두 구현들은 session-per-request로 알려지고 사용되고 있는 "하나의 세션 - 하나의 데이터베이스 트랜잭션" 프로그래밍 모형을 제공한다. 하나의 Hibernate 세션의 시작과 끝은 데이터베이스 트랜잭션의 존속 기간에 의해 정의된다. 만일 (예를 들면 순수 J2SE에서 또는 JTA/UserTransaction/BMT의 경우에) 당신이 프로그램 상의 트랜잭션 경계구분을 사용할 경우, 당신은 당신의 코드로부터 기본 트랜잭션 시스템을 은폐시키는데 Hibernate Transaction API를 사용하는 것이 권장된다. 만일 당신이 CMT를 지원하는 하나의 EJB 컨테이너에서 실행할 경우, 트랜잭션 경계들이 선언적으로 정의되고 당신은 당신의 코드 내에 어떤 트랜잭션도 세션 경계구분 오퍼레이션들을 필요로 하지 않는다. 

hibernate.current_session_context_class 구성 파라미터는 org.hibernate.context.CurrentSessionContext 구현이 사용될 것임을 정의한다. 역호환을 위해. 만일 이 구성 파라미터가 설정되지 않았지만 하나의 org.hibernate.transaction.TransactionManagerLookup이 구성되어 있을 경우, Hibernate는 org.hibernate.context.JTASessionContext를 사용할 것임을 노트하라. 일반적으로, 이 파라미터의 값은 단지 사용할 구현 클래스를 명명할 것이다; 하지만 두 가지 비공식적인 구현들로서 두 개의 대응하는 짧은 이름들 "jta"와 "thread"이 존재한다.