하이버네이트, 스프링, 트랜잭션, OSIV(Open Session In View) 패턴

참조

No Hibernate Session bound to thread 에러로 시작한 OSIV 얘기
http://forum.springframework.org/archive/index.php/t-33082.html

논쟁에서 언급한 HibernateTemplate API
http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/orm/hibernate3/HibernateTemplate.html

스프링의 OpenSessionInViewFilter API
http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/orm/hibernate3/support/OpenSessionInViewFilter.html

하이버네이트 위키 OSIV
http://www.hibernate.org/43.html

손권남님의 OSIV 정리
http://kwon37xi.springnote.com/pages/1075048

InfoQ에서 Spring In Production 요약한 것
http://www.infoq.com/news/2007/11/spring-production

댓글에 보면 OSIV 패턴이 안티 패턴인가에 대한 내용이 있음
http://blog.springsource.com/2007/11/09/download-the-spring-in-production-white-paper/

Tip4에서 OSIV 패턴은 안티 패턴이라고 한다.
http://www.realsolve.co.uk/site/tech/orm-performance.php

이미 세션이 닫힌 상태에서 뷰에서 Detached 객체에서 아직 로딩하지 않은 객체에 접근하면 에러(LazyInitializationException)가 발생합니다. 이 에러는 정상적인 에러죠. 하이버네이트 맵핑을 Lazy loading으로 최소한의 객체만 로딩하도록 하고 필요할 때 연관을 맺고 있는 객체를 추가로 가져오도록할 때 흔히 발생하는 아주 정상적인 에러입니다.

이런 상황을 극복하려면 필요한 객체를 미리 팻치(Eager Fatch)해둔 상태로 로딩하는 메소드를 DAO쪽에 구현해서 뷰에서 추가로 세션을 사용할 필요없이 뷰 랜더링을 마치도록 하면 되기도 하고..

아니면 OSIV 패턴을 사용해서, 인터셉터나 필터를 적용해서 뷰를 완전히 랜더링 할 때까지 세션을 열어 두는 겁니다. 그럼 뷰를 랜더링 하다가 필요한 객체가 있으면 세션을 사용해서 로딩할 수 있겠죠. 그럼 위의 방법처럼 DAO에 이른 팻치를 해서 가져오는 별도의 메소드나 쿼리를 만들지 않아도 되겠죠.

흠.. 하지만 뷰에서 자신도 예측하지 못한 쿼리가 계속 발생할 여지도 있고, 웹 단에서 데이터 캡슐화를 깨기 때문에 OSIV를 안티패턴으로 보고 사용을 최소화 해야 한다는 주장도 있습니다.

스프링 + 하이버네이트 조합을 쓸 때 OpenSessionInViewFilter를 자주 사용하는데, 이 API는 아주 잘 봐둘 필요가 있습니다. 그 중에서 가장 주목해야 할 부분은 다음과 같습니다.

1. 기본 플러시 모드는 FlushMode.NEVER입니다. NEVER는 deprecated 됐는데, 아직 사용하고 있습니다. 이 걸 왜 주의해야 하냐면, OSIV를 등록하고 만약 서비스 계층에 @Trasaction을 설정하지 않았다고 해봅시다. 그럴 때 트랜잭션 처리는 됩니다. 왜냐면 OSIV 때문이죠. 요청이 들어오면 해당 요청을 처리할 쓰레드에 새로운 세션 만들고 그걸로 트랜잭션 만들어서 쓰기 때문에 트랜잭션은 있는데 문제는 플러시 모드가 NEVER라서 명시적으로 flush()를 호출하기 전까지는 절대로 DB에 반영이 안 됩니다.

2. Conversation을 하나의 세션을 늘리는 방법(extending a sesion for conversation)으로 구현할 경우에, persistence 객체의 reassociation을 최대한 요청 처리 초기에 해야 합니다. 안 그럼 나중에 동일한 객체가 또 있다고 충돌 날 수가 있습니다. 이 문제에 대응하기 위해서 singleSession이라는 옵션에 false 값을 줄 수도 있지만, 그렇게 하면 매 요청 마다 새로운 Session 만들어서 사용하겠다는 것이고 Conversation을 구현하는 다른 방법(detached 객체를 가지고 구현하는 방법)으로 구현해야 될 것 같습니다. 즉 코딩할 때 조금 주의해서 단일 세션으로 Conversation을 사용할 것이냐, 아님 단순하게 요청 마다 새로운 세션으로 만들고 객체들을 붙였다 띄었다 할 것이냐 인데.. 필요한 객체를 계속 하나의 세션에 들고 유지하는게 좀 더 효율적이지 않을까 싶네요.

@Repository를 쓴다면 하이버네이트 예외 변환기 직접 만들 필요 없습니다.

스프링이 2.0부터 제공하고 있었는데, 이제서야 알게 됐습니다. 저는 그동안 뭘…;;;; 한 거죠.. ㅋㅋㅋ 이 것 참..;; 혹시 저만 빼고 다들 알고 계셨던건 아니겠죠? 저는 게다가 항상 @Repository 애노테이션을 쓰고 있었거든요. 그런데도 몰랐습니다. @Repository 애노테이션 API에도 안 나와있네요.

하이버네이트 예외 변환기가 언제 필요하냐면.
1. 하이버네이트 DAO 구현을 스프링 API에서 독립적으로 구현하고 싶을 때. 다른 말로 하이버네이트 SessionFacotry를 직접 주입해서 사용하고 싶을 때.
2. 하이버네이트 예외를 스프링 DataAccessException으로 변환하고 싶을 때.

위 두 가지 조건이 만족한다면 사용하고 싶을 겁니다. 그럴 때 만약 @Reposity라는 애노테이션으로 빈 스캔을 사용해서 빈을 등록하고 있다면 예외 처리기를 만들 필요 없이 빈 하나만 등록해주면 끝납니다.

<bean class=”org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor” />

끝~ 저 클래스는 이름이 암시하듯이 스프링의 빈 포스트 프로세서로, 등록된 빈 중에 @Repository가 붙어있는 빈에 persistenceExceptionTranslationAdvisor 이런 어드바이저를 적용한 프록시 빈으로 교체해주는 멋진 녀석입니다. AOP와 빈 포스프 프로세서의 조합. 캬오… 스프링엔 이렇게 멋진 코드가 곳곳에 숨어있군요.

핵심코드 감상 하기…

    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        Class<?> targetClass =
                (bean instanceof Advised ? ((Advised) bean).getTargetSource().getTargetClass() : bean.getClass());
        if (targetClass == null) {
            // Can’t do much here
            return bean;
        }
       
        if (AopUtils.canApply(this.persistenceExceptionTranslationAdvisor, targetClass)) {
            if (bean instanceof Advised) {
                ((Advised) bean).addAdvisor(this.persistenceExceptionTranslationAdvisor);
                return bean;
            }
            else {
                ProxyFactory proxyFactory = new ProxyFactory(bean);
                // Copy our properties (proxyTargetClass etc) inherited from ProxyConfig.
                proxyFactory.copyFrom(this);
                proxyFactory.addAdvisor(this.persistenceExceptionTranslationAdvisor);
                return proxyFactory.getProxy(this.beanClassLoader);
            }
        }
        else {
            // This is not a repository.
            return bean;
        }
    }

위 코드는 유겐 휄러와 로드 좐슨이 작성한 코드입니다.

ProxyFactory를 사용해서 직접 프록시 만드는 방법은 어제 올린 스크린 캐스팅에 포함되어 있었죠. Advised 인터페이스에 대해서도 언급 했었구요. 스프링 AOP 스캐를 보신 분들이라면 무리 없이 이해하실 수 있을 겁니다. 귿~

12.2.8. Transaction management strategies

TransactionTemplate 나 TransactionInterceptor 를 사용하든 둘 다 PlatformTransactionManager 객체를 사용하고 있습니다.
Hibernate를 위해 사용할 수 있는 TransactionManager로는 두 개가 있습니다.

1. HibernateTransactionManager :: for a single Hibernate SessionFactory, using a ThreadLocal  Session under the hood
2. JtaTransactionManager :: delegating to the JTA
subsystem of the container
물론 직접 PlatformTransactionManager 인터페이스를 구현해서 사용해도 됩니다.

따라서 단일 트랜잭션 리소스를 사용하다가 분산된 트랜잭션 처리가 필요할 때는 간단히 JtaTransactionManager를 사용하도록 수정하면 됩니다.

아래의 코드는 여러개의 LocalSessionFactoryBean 를 사용하여 Oracle과 MySQL JDBC를 사용하는 JtaTransactionManager 설정을 보여줍니다.

<beans>

  <bean id=”myDataSource1″ class=”org.springframework.jndi.JndiObjectFactoryBean”>
    <property name=”jndiName value=”java:comp/env/jdbc/myds1″/>
  </bean>

  <bean id=”myDataSource2″ class=”org.springframework.jndi.JndiObjectFactoryBean”>
    <property name=”jndiName” value=”java:comp/env/jdbc/myds2″/>
  </bean>

  <bean id=”mySessionFactory1″ class=”org.springframework.orm.hibernate3.LocalSessionFactoryBean”>
    <property name=”dataSource” ref=”myDataSource1″/>
    <property name=”mappingResources”>
      <list>
        <value>product.hbm.xml</value>
      </list>
    </property>
    <property name=”hibernateProperties”>
      <value>
        hibernate.dialect=org.hibernate.dialect.MySQLDialect
        hibernate.show_sql=true
      </value>
    </property>
  </bean>

  <bean id=”mySessionFactory2″ class=”org.springframework.orm.hibernate3.LocalSessionFactoryBean”>
    <property name=”dataSource” ref=”myDataSource2″/>
    <property name=”mappingResources”>
      <list>
        <value>inventory.hbm.xml</value>
      </list>
    </property>
    <property name=”hibernateProperties”>
      <value>
        hibernate.dialect=org.hibernate.dialect.OracleDialect
      </value>
    </property>
  </bean>

  <bean id=”myTxManager” class=”org.springframework.transaction.jta.JtaTransactionManager”/>

  <bean id=”myProductDao” class=”product.ProductDaoImpl”>
    <property name=”sessionFactory” ref=”mySessionFactory1″/>
  </bean>

  <bean id=”myInventoryDao” class=”product.InventoryDaoImpl”>
    <property name=”sessionFactory” ref=”mySessionFactory2″/>
  </bean>

  <!– this shows the Spring 1.x style of declarative transaction configuration –>
  <!– it is totally supported, 100% legal in Spring 2.x, but see also above for the sleeker, Spring 2.0 style –>
  <bean id=”myProductService”
      class=”org.springframework.transaction.interceptor.TransactionProxyFactoryBean”>
    <property name=”transactionManager” ref=”myTxManager”/>
    <property name=”target”>
      <bean class=”product.ProductServiceImpl”>
        <property name=”productDao” ref=”myProductDao”/>
        <property name=”inventoryDao” ref=”myInventoryDao”/>
      </bean>
    </property>
    <property name=”transactionAttributes”>
      <props>
        <prop key=”increasePrice*”>PROPAGATION_REQUIRED</prop>
        <prop key=”someOtherBusinessMethod”>PROPAGATION_REQUIRES_NEW</prop>
        <prop key=”*”>PROPAGATION_SUPPORTS,readOnly</prop>
      </props>
    </property>
  </bean>

</beans>

JTA가 JNDI에 종속적이기 때문에 JNDI를 사용하여 datasource를 가져오는 모습입니다. 단일 리소스를 사용할 경우에는 HibernateTracsactionManager를 사용하는 것이 좋으며 이 때는 datasource를 가져 올때 걍 평범하게 가져오면 됩니다.

12.2.7. Declarative transaction demarcation

이번엔 선언적인 트랜잭션 경계 설정에 관해 살펴보겠습니다. Spring AOP를 사용하는 방법으로 이전에는 Service Layer에 트랜잭션과 관련된 코드가 들어있었다면 Service Layer이 오직 자신의 본연의 임무에만 충실할 수 있도록 코드가 다음과 같이 바뛰게 됩니다.

public class ProductServiceImpl implements ProductService {

private ProductDao productDao;

public void setProductDao(ProductDao productDao) {
this.productDao = productDao;
}

// notice the absence of transaction demarcation code in this method
// Spring's declarative transaction infrastructure will be demarcating transactions on your behalf
public void increasePriceOfAllProductsInCategory(final String category) {
List productsToChange = this.productDao.loadProductsByCategory(category);
// ...
}
}

이전 글에서의 빨간색 글자 부분이 모두 사라졌으며 TransactionTemplate 변수 역시 필요없게 되었습니다. 이 말은 Spring 관련 API가 코드에서 사라졌다는 것이죠. 다시 또 말하면  Spring의 non-invasive 특징을 잘 나타내주고 있습니다.

Spring 1.2 방식의 AOP를 사용하여 트랜잭션 경계를 설정하는 방법은 다음과 같습니다.

<beans>

<bean id="myTxManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory" ref="mySessionFactory"/>
</bean>

<bean id="myProductService" class="org.springframework.aop.framework.ProxyFactoryBean">
<property name="proxyInterfaces" value="product.ProductService"/>
<property name="target">
<bean class="product.DefaultProductService">
<property name="productDao" ref="myProductDao"/>
</bean>
</property>
<property name="interceptorNames">
<list>
<value>myTxInterceptor</value> <!-- the transaction interceptor (configured elsewhere) -->
</list>
</property>
</bean>

</beans>

TransactionInterceptor 와 TransactionTemplate의 차이
* 발생 시키는 Exception 유형 :: Interceptor는 throwable 타입, Template은 transactionException 타입(Runtime Exception)
* 롤백 설정 단위 :: Interception 는 메소드마다 정책을 다르게 설정해 줄 수 있다. Template은 어플리케이션에서 사용하는 TransactionStatus 객체에 설정하기 땜시 단위가 다름.

위의 설정 내용을 Spring 2.0 방식으로 다음과 같이 간단하게 바꿀 수 있습니다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd">

<!-- SessionFactory, DataSource, etc. omitted -->

<bean id="myTxManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory" ref="mySessionFactory"/>
</bean>

<aop:config>
<aop:pointcut id="productServiceMethods" expression="execution(* product.ProductService.*(..))"/>
<aop:advisor advice-ref="txAdvice" pointcut-ref="productServiceMethods"/>
</aop:config>

<tx:advice id="txAdvice" transaction-manager="myTxManager">
<tx:attributes>
<tx:method name="increasePrice*" propagation="REQUIRED"/>
<tx:method name="someOtherBusinessMethod" propagation="REQUIRES_NEW"/>
<tx:method name="*" propagation="SUPPORTS" read-only="true"/>
</tx:attributes>
</tx:advice>

<bean id="myProductService" class="product.SimpleProductService">
<property name="productDao" ref="myProductDao"/>
</bean>

</beans>

12.2.6. Programmatic transaction demarcation

프로그래밍적인 방법으로 트랜잭션 경계를 지정하는 방법은 다음과 같이 비즈니스 로직 부분에 PlatformTransactionManager 를 인스턴스로 등록하고 Setter Injection을 사용하는 것입니다.

<beans>

<bean id="myTxManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory" ref="mySessionFactory"/>
</bean>

<bean id="myProductService" class="product.ProductServiceImpl">
<property name="transactionManager" ref="myTxManager"/>
<property name="productDao" ref="myProductDao"/>
</bean>

</beans>

아래의 코드를 통해 위 설정 내용이 어떻게 적용 되는지 확인할 수 있습니다.

public class ProductServiceImpl implements ProductService {

private TransactionTemplate transactionTemplate;
private ProductDao productDao;

public void setTransactionManager(PlatformTransactionManager transactionManager) {
this.transactionTemplate = new TransactionTemplate(transactionManager);
}

public void setProductDao(ProductDao productDao) {
this.productDao = productDao;
}

public void increasePriceOfAllProductsInCategory(final String category) {
this.transactionTemplate.execute(new TransactionCallbackWithoutResult() {

public void doInTransactionWithoutResult(TransactionStatus status) {
List productsToChange = this.productDao.loadProductsByCategory(category);
// do the price increase...
}
}
);
}
}

TransactionTemplate 객체를 사용하여 콜백과 템플릿을 사용하여 원하는 코드를 트랜잭션 처리 하에 처리하게 됩니다.

단점은 트랜잭션 처리할 부분에 빨간색의 코드들이 추가적으로 중복되게 됩니다. 이런 중복은 AOP를 사용하여 따로 빼낼 수 있는데요. 그런 방법을 다음 챕터인 선언적인 트랜잭션 경계 선언에서 알아보겠습니다.