Whiteship's Note


12.2.8. Transaction management strategies

Spring/Chapter 12 : 2007. 4. 27. 09:26


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를 가져 올때 걍 평범하게 가져오면 됩니다.


top

Write a comment.


12.2.7. Declarative transaction demarcation

Spring/Chapter 12 : 2007. 4. 25. 13:00


이번엔 선언적인 트랜잭션 경계 설정에 관해 살펴보겠습니다. 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>

top

Write a comment.


12.2.6. Programmatic transaction demarcation

Spring/Chapter 12 : 2007. 4. 25. 12:41


프로그래밍적인 방법으로 트랜잭션 경계를 지정하는 방법은 다음과 같이 비즈니스 로직 부분에 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를 사용하여 따로 빼낼 수 있는데요. 그런 방법을 다음 챕터인 선언적인 트랜잭션 경계 선언에서 알아보겠습니다.
top

Write a comment.


12.2.5. Implementing DAOs based on plain Hibernate3 API

Spring/Chapter 12 : 2007. 4. 25. 12:25


Hibernate 3.0.1 에서는 "Contexture Sessions"라고 부르는, 트랜잭션 당 하나의 current 세션을 사용하는 방법이 있습니다.
public class ProductDaoImpl implements ProductDao {

private SessionFactory sessionFactory;

public void setSessionFactory(SessionFactory sessionFactory) {
this.sessionFactory = sessionFactory;
}

public Collection loadProductsByCategory(String category) {
return this.sessionFactory.getCurrentSession()
.createQuery("from test.Product product where product.category=?")
.setParameter(0, category)
.list();
}
}
Spring 에서도 위와 같은 방법으로 코딩을 하면 트랜잭션 당 하나의 Hibernate Session객체를 사용하여 작업을 합니다.

위의 소스코드는 다음과 같은 DI가 필요합니다.
<beans>

<bean id="myProductDao" class="product.ProductDaoImpl">
<property name="sessionFactory" ref="mySessionFactory"/>
</bean>

</beans>
이런 스타일의 코딩의 장점은 Spring API에 종속 되지 않는 다는 것입니다. 오직 Hibernate API만 사용하고 있습니다.

단점은 HibernateException을 발생시키는데 이 것으로는 optimistic locking 이 실패 했다거나 하는 것을 알려주지 못합니다.

결론은 DAO를 구현할 때 Spring을 사용하여(HibernateTransactionManager) 트랜잭션 관리도 하고 DataAccessException을 사용할 수도 있지만 Hibernate3 API만 사용하여 구현할 수도 있습니다.
top

  1. Favicon of http://chanwook.tistory.com BlogIcon 찬욱 2007.04.25 13:11 신고 PERM. MOD/DEL REPLY

    하이버네이트 versioning을 사용하면 하이버네이트만 사용해도 Optimistic control이 가능해요~
    3.01에는 JTA 기반으로 생긴거구요, 3.1에 가면서 ThreadLocal 기반도 추가되었답니다~

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2007.04.25 14:54 신고 PERM MOD/DEL

    ㅇㅇ트랙백 쌩큐. Session per Request, Session per Transaction, Contexture Session 요거 다 같은 말인가 보군.

Write a comment.


레퍼런스 12장에 오타

Spring/Chapter 12 : 2007. 4. 24. 13:14


문제가 발생한 코드는 Spring Reference에 있던 소스 코드입니다.
public class ProductDaoImpl extends HibernateDaoSupport implements ProductDao {

public Collection loadProductsByCategory(String category)
throws DataAccessException, MyException {

Session session = getSession(getSessionFactory(), false);
try {
List result = session.find(
"from test.Product product where product.category=?",
category, Hibernate.STRING);
if (result == null) {
throw new MyException("invalid search result");
}
return result;
}
catch (HibernateException ex) {
throw convertHibernateAccessException(ex);
}
}
}
위 코드에 잘못된 부분이 getSession 메소드 뿐이 아니였습니다. 바로 아래에 있는 session.find()도 문제가 있습니다. find() 메소드는 Hibernate의 org.hibernate.classic 패키지의 Session 인터페이스에 있습니다. 그러나 보통 사용하는 Session은 org.hibernate 패키지의 Session 인터페이스이였습니다. 그리고 그곳에는 find()라는 메소드가 없지요.

classic 패키지에 있는 Session이 상위 패키지에 있는 Session 인터페이스를 상속하고 있습니다. 하지만.. 모든 인터페이스가 deprecated 됐습니다. -_-;;
사용자 삽입 이미지

굳이 deprecated된 인터페이스를 사용(org.hibernate.classic.Sessoin 사용)하는 예제코드의 의도를 살리려면 다음과 같이 코드가 바껴야 합니다.

import org.hibernate.classic.Session;

        Session session = (Session) getSession(false);
        try {
            List result = session.find("from test.Product product where product.category=?", category, Hibernate.STRING);
            if (result == null) {
                throw new MyException("invalid search result");
            }
            return result;
        }

org.hibernate.Session을 사용하려면 다음과 같이 코드를 바꿔야 합니다.

        Session session = getSession(false);
        try {
            List result = session.createQuery("from test.Product product where product.category=?").setString(0, category).list();
            if (result == null) {
                throw new MyException("invalid search result");
            }
            return result;
        }

구형 인터페이스를 사용하고 캐스팅을 사용하느냐(처음 것) 아니면 신형 인터페이스를 사용하여 캐스팅도 없애느냐(뒤에 있는 것). 의 문제 인데요. 당연히 후자가 되어야 적당하다고 생각합니다.

전자에서 사용한 인터페이스는 Hibernate2 부터 deprecated 된거라고 신형 Session을 사용하라고 API에도 나와있습니다.
An extension of the Session API, including all deprecated methods from Hibernate2. This interface is provided to allow easier migration of existing applications. New code should use org.hibernate.Session.
용겐 횔러 횽하 신형 API 사용해서 예제 수정 해주세욜~
top

Write a comment.


12.2.4. Implementing Spring-based DAOs without callbacks

Spring/Chapter 12 : 2007. 4. 24. 11:36


콜백 메소드를 사용하지 않고 HibernateDaoSupport로 부터 Session을 구해서 다음과 같이 코딩할 수 있습니다.

public class ProductDaoImpl extends HibernateDaoSupport implements ProductDao {

    public Collection loadProductsByCategory(String category)
            throws DataAccessException, MyException {

        Session session = getSession(getSessionFactory(), false);
        try {
            List result = session.find(
                "from test.Product product where product.category=?",
                category, Hibernate.STRING);
            if (result == null) {
                throw new MyException("invalid search result");
            }
            return result;
        }
        catch (HibernateException ex) {
            throw convertHibernateAccessException(ex);
        }
    }
}

이 때 유용하게 사용할 수 있는 메소드로는 역시 Session을 가져다 주는 getSession메소드 입니다.

희한하네요. getSession() 메소드의 인자가 두 개인 녀석이 안보이는데 레퍼런스에 있는 예제 코드가 잘못된 것 같습니다. 이 것도 이슈트랙에 올려야 겠군요. "용겐 휄러 횽하 예제 코드가 또 틀렸어효"

getSession(); getSession(boolean allowCreate); => HibernateDaoSupport 클래스에 있고
getSession(SessionFactory sessionFactory, boolean allowCreate); => SessionFactoryUtils 클래스에 있습니다.

어쨋든 allowCreate 속성은 Session을 만들 때 가져올 때 현재 트랜잭션에서 가져오느냐 아니면 새 트랜잭션에서 가져오느냐를 설정해 줍니다. true면 새거 false면 현재 트랜잭션을 사용하게 됩니다.

convertHibernateAccessException(ex); 메소드는 이름에서도 알 수 있듯이 Hibernate에서 발생하는 예외를 바꿔줍니다. unchecked Exception으로 바꿔주는 일을 하겠죠.

즉 하드코딩을 하더라도 Spring이 제공하는 예외 랩핑을 사용할 수 있지만 try-catch 보기도 싫고 굳이 예외 변경하는 코드를 매번 넣어야 하기 때문에 대부분의 경우 HibernateTemplate을 사용하는게 편할 것 같습니다.


top

  1. Favicon of http://jjaeko.tistory.com BlogIcon 째코 2008.05.13 14:37 PERM. MOD/DEL REPLY

    allowCreate가 true면 새거 false면 현재 트랜잭션이라고 했는데
    현재 트랙잭션은 현재 세션으로 말을 바꾸어도 되나요??

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2008.05.13 18:13 신고 PERM MOD/DEL

    네 어쩌면 현재 쓰레드라고 하는게 가장 정확할 수도 있곘습니다. 현재 쓰레드의 ThreadLocal에 session이 있으면 그걸 가져오고 없으면 새로 만들기인데..

    보통 있어야 하는데 없는 경우 무슨 문제가 생긴 것이기 때문에 true로 해서 새로 만들고 문제를 덮을 수도 있겠지만, false로 해서 왜 현재 쓰레드에 묶인 세션이 없는건지 확인하는게 좋겠죠.

Write a comment.


12.2.3. The HibernateTemplate

Spring/Chapter 12 : 2007. 4. 23. 19:04


이 전 글에서 Spring Container에 등록한 SessionFactoryBean을 사용하여 HibernateTemplate을 생성할 수 있습니다.

따라서 HibernateTemplate을 사용할 DAO 클래스에 setter injection을 사용하기 위해 보통 다음과 같이 설정합니다.
<beans>

  <bean id="myProductDao" class="product.ProductDaoImpl">
    <property name="sessionFactory" ref="mySessionFactory"/>
  </bean>

</beans>

어플리케이션에서 사용할 때는 다음과 같이 콜백을 사용하여 session에 접근합니다.
public class ProductDaoImpl implements ProductDao {

    private HibernateTemplate hibernateTemplate;

    public void setSessionFactory(SessionFactory sessionFactory) {
        this.hibernateTemplate = new HibernateTemplate(sessionFactory);
    }

    public Collection loadProductsByCategory(final String category) throws DataAccessException {
        return this.hibernateTemplate.execute(new HibernateCallback() {
            public Object doInHibernate(Session session) {
                Criteria criteria = session.createCriteria(Product.class);
                criteria.add(Expression.eq("category", category));
                criteria.setMaxResults(6);
                return criteria.list();
            }
        };
    }
}

HibernateTemplate이 Session의 생성이나 소멸, 트랜잭션을 책임집니다. 따라서 콜백을 사용하여 단순하게 할 일(find, select, insert 등) 만 코딩해 주면됩니다.

HibernateTemplate의 execute() 메소드 소스 코드를 보시면 어떤 일을 해주는지 짐작할 수 있습니다.

한 단계 더 나가서 HibernateTemplate을 DAO 클래스 내부에 직접 멤버 변수로 선언하지 않고 DAO 클래스가 HibernateDaoSupport 클래스를 상속 받도록 하면 getHibernateTemplate() 메소드르 사용하여 원할 때 마다 HibernateTemplate을 사용할 수 있습니다.

public class ProductDaoImpl extends HibernateDaoSupport implements ProductDao {

    public Collection loadProductsByCategory(String category) throws DataAccessException {
        return this.getHibernateTemplate().find(
            "from test.Product product where product.category=?", category);
    }
}

이런식으로 사용하면 DAO마다 setter injection 해야하는 수고를 덜 수 있겠습니다.
top

  1. Favicon of http://chanwook.tistory.com BlogIcon 찬욱 2007.04.23 19:39 신고 PERM. MOD/DEL REPLY

    이상하게 이 글로 트랙백이 안가요 -0-; 왜그럴까요~

    Favicon of http://whiteship.tistory.com BlogIcon 기선 2007.04.23 21:12 PERM MOD/DEL

    흠;;; 글쎄 왜그러지;; 댓글로라도 링크 주렴~

  2. Favicon of http://jjaeko.tistory.com BlogIcon 째코 2008.05.13 17:34 PERM. MOD/DEL REPLY

    HibernateTemplate 뜯어 봤는데...
    만약 트랜잭션매니저를 사용중이면 절대 flush하지 않고 close하지도 않더군요..
    반면 트랜잭션매니저를 사용하지 않을 경우 flush는 모르겠고 close하구여
    오퍼레이션시 예외 발생하면 Spring 공통 런타임 예외인 DataAccessException으로 번역하는거..
    이거 말고는 딱히 다른 작업을 하지 않은것 같습니다... 저는 솔직히 HibernateTemplate 쓰는 장점 모르겟어요 어차피 Hibernate Session으로 작업해도 체크되지 않은 예외 던지기 때문에 예외번역의 효과는 미미하고.. 트랜잭션관리야 뭐 서비스레이어에서 @Transactional로 처리하는거고... 큰 장점은 모르겠네요..
    iBatis일 경우는 sqlMapClient의 메서드가 SQLException을 던지기 때문에 예외번역 효과가 커서 이익이지만... Hibernate의 경우 큰 메리트는 못느끼겠네요... 기선님이 장점에 대해서 좀 알려주세요...

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2008.05.13 18:20 신고 PERM MOD/DEL

    맞습니다. 저도 요즘하고 있는 프로젝트에선 HibernateTemplate이나 HibernateSupport 클래스를 사용하지 않습니다.

    굳이 장점이라고 한다면, 템플릿 코드를 사용해서 세션 열고 닫는 일을 줄여주고, 언급하신 DAE으로의 변경인데요.

    트랜잭션을 Service 계층에서 열고 닫기로 하면(서비스 계층에 @Transactional 붙여주면 그렇게 되죠.) DAO에서는 getCurrentSession()으로 Session 가져와서 원하는 작업만하면 됩니다. 기타 Session 열고 닫고 트랜잭션 열고 커밋 또는 롤백하는 일은 서비스 계층에 적용된 트랜잭션 매니저가 알아서 해주겠죠.

    남은 하나는, 하이버예외를 스프링의 DAE(Data Access Exception)으로 바꾸는 작업인데, 이 작업 마저도 하이버 3쩜에 와서 별로 필요없어진게.. 하이버도 3쩜대 부터는 Uncached Exception으로 예외 타입을 바꿨고, 스프링 만큼이나 풍부한(거의 동일한 갯수 였던걸로 기억하는데 자세힌 몰겠습니다.) 예외 계층 구조를 가지고 있습니다. 그래도 굳이.. 또 스프링 DAE로 바꾸고 싶다면, 간단한 Aspect 하나만 만들어서 적용하면 됩니다.(http://whiteship.tistory.com/1491)

    따라서.. '기호'의 문제이지만, 전 보다 코드가 간결하고 깔끔한 getCurrentSession()이 더 좋습니다. DAO에 SessionFactory를 DI하고 사용하는거죠.

  3. Favicon of https://jjaeko.tistory.com BlogIcon 째코 2008.05.13 17:55 신고 PERM. MOD/DEL REPLY

    결정적으로 페이징 메서드를 제공하지 않더군요..
    기선님은 이부분 어떻게 해결하시나요?

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2008.05.13 18:38 신고 PERM MOD/DEL

    이게 화면의 그리드 부터 컨트롤러, 서비스, DAO까지 쭉 연결되는 거라 간단하지 않은것 같습니다.

    스프링이 제공하는 PagedListHolder라는 걸 확장해서(아니면 새로운 클래스를 만들어서) 하이버네이트의 Criteria에 페이징 관련 설정을 추가해주는 등의 페이징 기능을 하는 메소드를 구현하셔야 될 것 같습니다.

  4. Favicon of https://jjaeko.tistory.com BlogIcon 째코 2008.05.13 19:29 신고 PERM. MOD/DEL REPLY

    페이징 구현하기도 귀찮고 어차피 체크되지 않은 예외던지기고 한마디로 Hibernate는 걍 오리지날 방식이 편할듯 싶네요... 혼자 이걸 어떻게 써야 이득을 볼까 고민 했는데 기선님 말씀 듣고보니 사용할 필요성이 팍 없어지네요..
    단 iBATIS의 경우는 예외번역의 메리트가 있기 때문에 Template을 쓰는게 좋겠네요~

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2008.05.13 19:55 신고 PERM MOD/DEL

    페이징 기능은 OSAF 2.0이 공개되면 알아서 해줍껍니다.
    캬캬캬 ^^

    하이버 3쩜대를 사용할 경우 HibernateTemplate은 별 메릿트가 없습니다. 괜히 코드만 지져분해지는 느낌이죠. getHibernateTemplate().excecute(new HibernateCallBack() { //진짜 필요한 코드 }); 이런식이니까요.

  5. Favicon of https://jjaeko.tistory.com BlogIcon 째코 2008.05.13 20:11 신고 PERM. MOD/DEL REPLY

    우엇 OSAF 2.0 기대 댑니당
    OSAF에서 어떤 기능을 제공 하나영?

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2008.05.13 20:44 신고 PERM MOD/DEL

    Generic(DAO, Service, Controller, PropertyEditor), Code Generation, Custom Tag(슈퍼 초 울트라 올마이티 Grid 포함, IE/FF 호환 가능 웹 표준), Convention Over Configuration, Web Support(Paging), Test Support, Spring Security Support, 각종 Utils 및 기타 등등등 으로 계속해서 기능 추가 및 개발 중입니다.

    올해가 가기전에 일부는 공개 할지도...

  6. Favicon of http://jjaeko.tistory.com BlogIcon 째코 2008.05.13 22:48 PERM. MOD/DEL REPLY

    테스트 해봤는데 결과부터 말씀드리자면
    DAO에서 sessionFactory.getCurrentSession() 으로 가져오면 안되는 군요...
    안되는 이유는 이렇습니다.
    getCurrentSession()으로 가져온 Session은 Proxy 객체인거는 당연히 아시겠지만...
    그 Proxy안에 들어 있는 Session은 서비스 레이어에서 @Transactional 애노테이션으로 인해 적용된
    TransactionInterceptor에서 트랜잭션을 시작한 Session과 서로 다르더군요...
    따라서 getCurrentsession로 얻어온 세션은 반드시 트랜잭션을 시작해야 하는데 그렇지 못하니까
    트랜잭션이 시작되지 않았다는 예외가 발생 합니다.
    서비스 레이어에 @Transactional로 열려진 트랜잭션의 세션을 가져오려면 HibernateDaoSupport의 getSession() 메서드을 통해야만 동일한 세션을 가져오네요...

    Favicon of http://whiteship.tistory.com BlogIcon 기선 2008.05.13 23:09 PERM MOD/DEL

    흠.. 그럴리가요. 엄연히 스프링 레퍼런스에도 나와있는 방법인데다가. http://whiteship.tistory.com/752 저는 현재 프로젝트에서 그런식으로 잘 사용하고 있습니다. 뭔가 설정을 잘못하신거 아닐까요?

    게다가 정말 getCurrentSession()이 반환한는 Session 객체가 Proxy인가요?? 흠;;; 몰랐는데요. Session 객체를 갈아치울 일도 없고 나중에 가져와야할 필요도 없는데 왜 프록시 객체일까요??

    테스트 하신 코드와 XML, 로그메시지 등을 째코님 블로그에 올려주실 수 있나요? 궁금합니다. 전 그렇게 매우 깔끔하게 잘 쓰고 있거든요;;

  7. Favicon of http://jjaeko.tistory.com BlogIcon 째코 2008.05.13 23:35 PERM. MOD/DEL REPLY

    앗... 삽질 했네요. ㅋㅋㅋㅋ
    문제가 뭔지 알아 냈습니다.
    <prop key="hibernate.current_session_context_class">thread</prop>
    이 설정 때문이군요... -0-;
    위 설정을 제거 하면 디폴트로 SpringSessionContext가 등록되는데 소스를 확인해보니 getCurrentSession() 구현이 서비스레이어에서 열어놓은 세션을 가져오도록 되어 있네요..
    저것의 설정값을 뭘로 해야될까 생각하다가 기선님 블로그에서 스크린캐스팅에 thread로 되어 있길래 -_- thread 구나! 하고 설정 한건데 서비스레이어에서 열어놓은 세션이 저장되는 곳은 쓰레드로컬이 아닌 Spring자체 SessionContext라서 그 동안 서로 엄한거 찾아 와서 그랬나봐요..
    오늘 SpringSessionContext가 있다는 사실은 첨 알았네요..

    Favicon of http://whiteship.tistory.com BlogIcon 기선 2008.05.13 23:51 PERM MOD/DEL

    네 하이버네이트의 CurrentSessionContext 인터페이스를 스프링이 구현해서 스프링이 관리하는 현재 Session 객체를 반환하도록 구현한 클래스죠.

    하이버네이트가 확장지점 만들어주고 스프링이 그걸 확장해서 스프링이 원하는 방식(비침략적인 방식)으로 구현해서 끼워넣은거죠. 사이좋은 스프링과 하이버.. 그로 인해 하이버의 SessionFactory만 사용해서 DAO를 구현하는 것이 가능해진거라고.. 토비 사부한테 배웠는데 이렇게 다시 알게 되다니 재밌네요.

    훔.. 근데 이상한건... 전 hibernate.current_session_context_class 이 설정 모르던 건데요. ㅋㅋㅋ 어디서 보신거에요?

    이거 이거 동영상 올리며 안 되는겠는데요~~ 제가 쓰는 세션팩터리 설정은 네 다섯개 밖에 안 되는데요.

    <prop key="hibernate.dialect">org.hibernate.dialect.HSQLDialect</prop>
    <prop key="hibernate.show_sql">true</prop>
    <prop key="hibernate.format_sql">false</prop>
    <prop key="hibernate.hbm2ddl.auto">update</prop>
    <prop key="hibernate.connection.autocommit">false</prop>

    그리고 아시겠지만, getCurrentSession()이 반환하는 Sssion 객체는 Proxy가 아니라 그냥 일반 객체죠? 프록시 객체일 필요가 없자나요.

  8. Favicon of http://jjaeko.tistory.com BlogIcon 째코 2008.05.14 00:24 PERM. MOD/DEL REPLY

    아까 제가 Proxy라고 말했던 상황은 제가 실수해서 session_context를 쓰레드로컬로 잘못 지정한 상황이었죠... ThreadLocalSessionContext 의 currentSession 메서드에서 다음 메서드를 호출 하네요..
    protected Session wrap(Session session) {
    TransactionProtectionWrapper wrapper = new TransactionProtectionWrapper( session );
    Session wrapped = ( Session ) Proxy.newProxyInstance(
    Session.class.getClassLoader(),
    SESS_PROXY_INTERFACES,
    wrapper
    );
    // yick! need this for proper serialization/deserialization handling...
    wrapper.setWrapped( wrapped );
    return wrapped;
    }
    JDK Proxy 사용하는거 맞죠?

    Favicon of http://whiteship.tistory.com BlogIcon 기선 2008.05.14 08:28 PERM MOD/DEL

    흠~ 그렇군요. 저런 클래스가 있는지도 몰랐네요.

Write a comment.


12.2.2. SessionFactory setup in a Spring container

Spring/Chapter 12 : 2007. 4. 23. 10:56


Spring 의 Application Context에 SessionFactory를 bean으로 등록해 둡니다.

다음은 Reference에 있는 XML 기반의 Hibernate 설정 파일을 사용할 때 등록하는 방법입니다.
<beans>

  <bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
    <property name="driverClassName" value="org.hsqldb.jdbcDriver"/>
    <property name="url" value="jdbc:hsqldb:hsql://localhost:9001"/>
    <property name="username" value="sa"/>
    <property name="password" value=""/>
  </bean>

  <bean id="mySessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
    <property name="dataSource" ref="myDataSource"/>
    <property name="mappingResources">
      <list>
        <value>product.hbm.xml</value>
      </list>
    </property>
    <property name="hibernateProperties">
      <value>
        hibernate.dialect=org.hibernate.dialect.HSQLDialect
      </value>
    </property>
  </bean>

</beans>

다음은 찬욱이가 만들어 둔 어노테이션을 사용하는 Hibernate 설정을 사용했을 때의 SessionFactoryBean을 등록하는 예입니다. dataSource는 어딘가 다른 곳에 있습니다.
    <bean id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
        <property name="dataSource" ref="dataSource" />
        <property name="annotatedClasses">
            <list>
                <value>buyingBook.model.Member</value>
            </list>
        </property>
        <property name="hibernateProperties">
            <props>
                <!-- 지금 사용하고 있는 데이터베에스에 최적화 된 SQL을 생성하기 위해서
                      현재 데이터베이스에 해당하는 Hibernate dialect 클래스 명 -->
                <prop key="hibernate.dialect">${hibernate.dialect}</prop>

                <!--  콘솔 창에 사용하는 모든 SQL문을 출력할지를 선택  -->
                <prop key="hibernate.show_sql">true</prop>

                <!-- DB Schema에 변경사항이 발생한 경우 자동으로 수정  -->
                <prop key="hibernate.hbm2ddl.auto">update</prop>

                <!-- 성능 튜닝에 도움이 되는 유용한 통계를 제공  -->
                <prop key=" hibernate.generate_statistics">true</prop>

                <!-- 자동 커밋이 되는 것을 방지 -->
                <prop key="hibernate.connection.autocommit">false</prop>

                <!-- "Current" Session의 Scope 설정.<jta/thread/managed/custom> -->
                <prop key="hibernate.current_session_context_class">thread</prop>
            </props>
        </property>
    </bean>

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

어플리케이션에서 "sessionFactory"로 빈을 룩업하면 SessionFactory type의 객체를 반환합니다. 빨간색 클래스들의 상위 클래스인 AbstractSessionFactoryBean 클래스의 코드 일부를 참조하면 알 수 있습니다.
사용자 삽입 이미지

만약에 사용하는 ORM이 바뀌면 여기서 설정파일만 바꿔주면 됩니다. 예를 들어 JNDI에 있는 DataSource를 사용할 거라면 다음과 같이 바꿔줍니다.
<beans>

  <bean id="myDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName" value="java:comp/env/jdbc/myds"/>
  </bean>

</beans>

top

Write a comment.


12.2.1. Resource management

Spring/Chapter 12 : 2007. 4. 23. 00:46


자원을 관리하는 코드가 보통 사방에 흩어져 있게 됩니다. 하지만 스프링에서는 이런 자원 관리간단하면서도 강력한 방법인 tamplate을 사용한 IoC를 이용해서 관리합니다. 자원을 관리하는 기능과 SQLException을 보다 구체적이고 un-checked Exception인 DataAccessException으로 래핑해줍니다.

HibernateTemplate, HibernateInterceptor, HibernateTransactionManager 이런 클래스들을 제공하는 가장 주요한 목적
1. 어플리케이션에서 Data Access와 Transaction 기술을 깔끔하게 레이어링
2. 어플리케이션 객체들 간의 Loose Coupling

따라서...
1. no more business service dependencies on the data access or transaction strategy
2. no more hard-coded resource lookups
3. no more hard-to-replace singletons
4. no more custom service registries.


top

Write a comment.


12.2. Hibernate

Spring/Chapter 12 : 2007. 4. 22. 00:11


ORM 중에 Hibernate와 연동하는 방법을 살펴보겠습니다. 예제들은 Hibernate 3.0을 사용하였습니다.

12.2.1. Resource management

12.2.2. SessionFactory setup in a Spring container

12.2.3. The HibernateTemplate

12.2.4. Implementing Spring-based DAOs without callbacks

12.2.5. Implementing DAOs based on plain Hibernate3 API

12.2.6. Programmatic transaction demarcation

12.2.7. Declarative transaction demarcation

12.2.8. Transaction management strategies

12.2.9. Container resources versus local resources

12.2.10. Spurious application server warnings when using Hibernate


top

Write a comment.


12.1. Introduction

Spring/Chapter 12 : 2007. 4. 21. 23:54


 ORM DAO를 만들 때 Spring Framwork를 사용하면...

- 테스트 하기 편합니다.

Spring IoC 컨테이너를 사용할 수 있기 때문에 퍼시스턴스 관련 코드를 고립된(isolated) 상태로 테스트를 하는 것이 훨씬 용이합니다.

-Data Access Exception을 제공합니다.

ORM에서 발생하는 checked 예외를 감싸서 unchecked 예외인 DataAccessException 을 발생 시킵니다. 예외 처리하고 싶으면 해도 되고 안 해도 되기 때문에 try/catch 문을 제거 할 수 있습니다.

-일관된 자원 관리를 할 수 있습니다.

Spring은 Hibernate를 위한 SessionFactory, JDBC를 위한 DataSource, iBatis SQL Maps 설정과 속성을 위한 자원(resource)를 관리할 수 있습니다. 따라서 이들의 관리와 변경이 용이합니다.

-통합된 트랜잭션 관리를 할 수 있습니다.

O/R mapping 코드를 선언적인 방법 또는 프로그래밍 적인 방법의 트랜잭션 관리로 감쌀 수 있습니다. 두 방법 중 어떤 걸 사용하든 모두 원하는 대로 트랜잭션을 설정할 수 있으며 예외가 발생했을 때 원하는데로 처리(ex. 롤백) 할 수 있습니다. 또한 Hibernate나 JDO 관련 코드의 변경 없이 트랜잭션 관리자만 바꿀 수 있습니다.

이것에 대한 예제는 Spring 소스코드를 받으면 딸려 오는 sample 코드 중에 jpetstore 와 petclinic에 보시면 나와있습니다.

사용자 삽입 이미지

사용자 삽입 이미지

top

Write a comment.


Chapter 12. Object Relational Mapping (ORM) data access

Spring/Chapter 12 : 2007. 4. 19. 21:39


12.1. Introduction

Hibernate, JDO, Oracle TopLink, iBATIS SQL Maps, JPA 같은 ORM 과 Spring을 통합하여 Spring 의 Transaction 관리과 Exception 정책을 사용할 수 있습니다.

통합 하는 방법은 두 가지
1. using Spring's DAO 'templates'.
2. coding DAOs against plain Hibernate/JDO/TopLink/etc APIs.

12.2. Hibernate

Hibernate 와 연동하는 방법을 설명합니다. 주로 Hibernate 3.0 중심으로 설명 합니다.

12.3. JDO

Spring supports the standard JDO 1.0/2.0 API as data access strategy

12.4. Oracle TopLink

Since Spring 1.2, Spring supports Oracle TopLink (http://www.oracle.com/technology/products/ias/toplink) as data access strategy

TopLink 9.0.4, 10.1.3

12.5. iBATIS SQL Maps

The iBATIS support in the Spring Framework much resembles the JDBC / Hibernate support in that it supports the same template style programming and just as with JDBC or Hibernate, the iBATIS support works with Spring's exception hierarchy and let's you enjoy the all IoC features Spring has.

12.6. JPA

Spring JPA offers comprehensive support for the Java Persistence API in a similar manner to the integration with Hibernate or JDO

12.7. Transaction Management

선언적인 트랜잭션 관리를 위한 설정 내용 입니다.
위 예제는 JpaTransactionManager를 사용한 경우입니다. Hibernate, Toplink, OpenJPA 를 위한 클래스도 제공합니다.

12.8. JpaDialect

Dialect 클래스를 사용함으로써 얻을 수 있는 장점들은 다음과 같습니다.
* applying specific transaction semantics (such as custom isolation level or transaction timeout)
* retrieving the transactional JDBC Connection (for exposure to JDBC-based DAOs)
* advanced translation of PersistenceExceptions  to Spring DataAccessExceptions

JDBC connection의 편리한 사용과 Transaction 그리고 DataAccessExcepion에 대한 장점은 10장, 11장에 이어 12장에서 까지 계속 얘기하네요.
top

Write a comment.