7. iBATIS + Spring + transaction

<tx:advice> 태그 이용

@ Transactional 어노테이션을   이용

6. iBATIS + Spring

스프링의 iBATIS 연동지원
 

iBATIS 에서 데이터베이스 연동을 처리할 때 사용되는 SqlMapClient 역시 JDBC 프로그램을 할 때와 마찬가지로 try-catch 블록을 사용해서 예외를 처리해 주어야 한다 .
또한 에러원인에 따라 알맞은 예외를 발생시키기보다는 SQLException 을 발생하고 있다 .

스프링은 SqlMapClient 를 사용할 때 발생하는 코드 중복을 없애고 SQLException 을 스프링이 제공하는 예외 클래스로 변환해 주는 SqlMapClientTempalte 클래스를 제공하고 있다 .

1. SqlMapClient 를 위한 스프링 설정

스프링이 제공하는 SqlMapClientTemplate 클래스는 내부적으로 iBATIS 의 SqlMapClient 를 사용한다 .
스프링은 SqlMapClient 를 스프링 설정 파일에서 쉽게 설정할 수 있도록 돕는 SqlMapClientFactoryBean 클래스를 제공하고 있다 .
이 클래스를 사용하면 SqlMapClient 를 스프링 빈으로 설정할 수 있다 .
dataSource 프로퍼티에는 DataSource 를 전달하며 , configLocation 프로퍼티는 iBATIS 설정 파일을 명시

2. SqlMapClientTemplate 을 이용한 DAO 구현

SqlMapClient 를 위한 빈을 설정했다면 SqlMapClientTemplate 을 이용해서 iBATIS 를 연동할 수 있다 .
SqlMapClientTemplate 클래스는 iBATIS 의 SqlMapClient 클래스가 제공하는 대부분의 메소드와 동일한 이름과 파라미터 타입 , 리턴 타입을 갖는 메소드를 정의하고 있다.
차이점이 있다면 SQLException 을 발생하는 대신 스프링이 제공하는 예외를 발생한다 .

iBATIS 의 SqlMapExecutor 를 직접 사용하고 싶다면 , SqlMapClientCallback 인터페이스의 구현 객체를 전달받는 execute() 메소드를 사용하면 된다 .

SqlMapClientCallback 구현 객체의 doInSqlMapClient() 메소드에 SqlMapExecutor 파라미터가 전달되므로 , 직접 SqlMapExecutor 를 사용해서 데이터베이스 연동을 구현할 수 있다 .
 

3. SqlMapClientDaoSupport 클래스를 이용한 DAO 구현

스프링은 SqlMapClientTemplate 클래스를 DAO 클래스에서 좀 더 쉽게 사용할 수 있도록 하기 위해 SqlMapClientDaoSupport 클래스를 제공한다 .

이 클래스를 상속받은 클래스는 sqlMapClientTemplate 프로퍼티를 통해서 SqlMapClientTemplate 를 전달받는다 .

Generic Tools에는,

DateTool

A tool for manipulating and formatting dates.

MathTool

A tool for performing floating point math.

NumberTool

A tool for formatting numbers.

RenderTool

A tool to evaluate and render arbitrary strings of VTL (Velocity Template Language).

EscapeTool

A tool to help with common escaping needs in Velocity templates.

ResourceTool

A tool to simplify access to ResourceBundles for internationalization or other dynamic content needs.

Alternator and AlternatorTool

Utility class for easily alternating over values in a list and tool for easy creation of Alternators in templates.

ValueParser

A tool to retrieve and parse String values pulled from a map. This provides the basis for the ParameterParser in VelocityView.

ListTool

A tool to help when working with arrays or Lists. This tool transparently handles both the same way.

SortTool

A tool that allows a user to sort a collection (or array, iterator, etc) on any arbitary set of properties exposed by the objects contained within the collection.

IteratorTool

A convenience tool to use with #foreach loops. It wraps a list to let the designer specify a condition to terminate the loop, and reuse the same list in different loops.

[Velocity] 스프링 프레임워크에서 사용하기

빈의 후처리

스 프링은 빈의 생명주기에 끼어들어 빈의 설정을 재검토하거나 바꿀 수 있는 2개의 기회를 제공한다. 후처리는 어떤 이벤트가 발생한 후에 처리되는 것이라고 추측할 수 있다. 이벤트란 빈이 설정되거나 인스턴스화되는 것을 말한다. BeanPostProcessor 인터페이스는 빈이 생성되거나 묶인 후에 변경할 수 있는 두개의 기회를 제공

빈 팩토리의 후처리

BeanFactoryPostProcesor는 빈 팩토리가 빈의 정의를 로딩한 후와 빈이 인스턴스화되기 전에 빈 팩토리에 대해 후처리를 수행한다.

BeanFactoryPostProcessor의 유용한 구현 클래스 두 개

PropertyPlaceholderConfigurer

CustomEditorConfigurer

자동 묶기(Autowire)

자동 묶기의 네 종류

byName : 묶고자 하는 특성의 이름과 동일한 이름이나 ID를 가진 빈을 컨테이너에서 찾는다. 빈을 찾지 못하면 그 특성을 묶이지 않은 채로 남는다.

byType : 묶 고자 하는 특성의 타입과 동일한 타입을 가진 빈을 컨테이너에서 찾는다. 빈을 찾지 못하면 그 특성은 묶이지 않은 채로 남고, 하나 이상의 빈을 찾게 되면 org.springframework.beans.factory.UnsatisfiedDependencyException을 던진다.

Constructor : 묶고자 하는 빈의 생성자 중 하나의 파라미터와 맞는 하나 이상의 빈을 컨테이너에서 찾는다. 모호한 빈이나 생성자가 발견될 경우 org.springframework.beans.factory.UnsatisfiedDependencyException을 던진다.

Autodetect : constructor에 의한 자동 묶기를 먼저 시도한 다음, byType을 이용한다. 모호함이 발견될 경우 constructor와 byType 경우와 동일한 방법으로 처리한다.

자동 묶기의 모호성 다루기

byType 이나 constructor를 사용하여 자동 묶기를 하는 경우에는 컨테이너가 특성의 타입이나 생성자 인자의 타입에 부합하는 둘 이상의 빈을 찾는 것이 가능하다.

이렇듯 자동 묶기에 사용될 수 있는 모호한 빈들이 존재 할 경우 스프링은 모호성을 분별할 능력이 없으며, 묶고자 하는 빈을 추측하는 대신 예외를 던지는 방법을 선택한다.

자동 묶기를 할 때 그 같은 모호성을 만나게 된다면, 자동 묶기를 하지 않는 것이 가장 단순하면서도 좋은 해결책이다.

세터 주입(Setter Injection)의 대안 - 생성자 주입(Constructor Injection)

세터 주입은 빈 특성을 설정하고 묶을 수 있는 직관적인 방법이지만, 한 가지 단점은

변경될 수 있는 모든 특성이 세터 메소드를 통해서 사용할 수 있다고 가정하는 것에 있다. 하지만 빈이 이와 같은 방식으로 작동하기를 원하지 않을 때,

이런 유형의 빈이 인스턴스화될 때에는 어떤 특성도 설정될 수 없으며, 따라서 빈이 유효하지 않은 상태로 있을 가능성이 있다.

어떤 특성들은 빈이 생성될 때 한 번만 설정되고 그 이후에는 변경될 수 없도록 만들고 싶은 경우도 있다.

이는 세터를 통해 모든 특성을 공개하는 경우에는 곤란해진다.

대안은 일부 특성들은 생성자 를 통해 설정될 수 있도록 빈을 설계하는 것이다.

DAO의 DataSource와 같이 반드시 설정돼야 하고 변경되어서는 안 되는 특성이 있는 경우에 특히 유용

빈 묶기(Bean wiring)

XML로 묶기 : 다음을 이용해 스프링 컨테이너가 XML을 통한 빈 묶기를 지원한다.

XmlBeanFactory

ClassPathXmlApplicaionContext

FileSystemXmlApplicationContext

XmlWebApplicationContext

프로토타입과 싱글톤 비교

스프링의 모든 빈은 싱글톤. getBean()의 호출에 의해서든 묶기를 통해서든 간에, 컨테이너가 빈을 배포할 때에는 항상 그 빈의 완전히 동일한 인스턴스를 내줄 것이다.

scope="singleton"
scope="prototype"

프로토타입 빈을 정의하는 것이 유리할 때

프로토타입을 정의한다는 것은 실제 하나의 빈을 정의하는 것이 아닌, 청사진을 정의한다는 의미다. 그 다음엔 그 청사진을 바탕으로 빈들이 생성될 것이다.

프로토타입 빈은, 빈을 요청할 때마다 컨테이너가 빈의 유일한 인스턴스를 제공하기 원하면서도 그 빈의 하나 이상의 특성을 스프링을 통해 설정하고자 할 경우에 유용

프로토타입으로 정의

빈 의 이름을 사용해 getBean()을 호출할 때마다 프로토타입의 새로운 인스턴스가 생성된다. 이로 인해 데이터베이스나 네트워크 연결과 같은 제한된 자원을 사용하는 빈의 경우에는 적합하지 않다. 최소한 새로운 인스턴스가 생성될 때마다 약간의 성능 저하를 겪을 수 있기 때문에, 절대적으로 필요한 경우에만 프로토타입으로 빈을 정의하자.

초기화와 소멸

빈의 정이 내에 커스텀 init-method를 선언함으로써 빈이 인스턴스화되는 즉시 호출될 메소드를 지정할 수 있다.

커스텀 destroy -method는 빈이 컨테이너로부터 제거되기 직전에 호출될 메소드를 지정한다.

Example) 커넥션 풀링(connection pooling) 빈

public class MyConnectionPool{

public void initialize(){

//커넥션 풀 초기화

}

}

public void close(){

//연결 해제

}

}

빈의 정의는,

MyConnectionPool이 인스턴스화되자마자 initialize() 메소드가 호출,

빈이 컨테이너로부터 제거되기 직전에 close() 메소드를 호출

스프링은 또 다른 방법으로, InitializingBean과 DisposableBean이라는 동일한 역할을 하는 두개의 인터페이스를 제공한다.

이 방법은 인터페이스를 구현하는 빈을 스프링 컨테이너가 자동으로 탐지하며, 별다른 설정없이도 메소드를 호출해준다(XML 손대지 않고) 하지만, 인터페이스를 구현하게 되면, 빈은 스프링의 API에 묶이게 되어 버린다.

빈을 초기화하고 소멸시킬 때 가능하다면 init-method와 destroy-method 정의에 의존하는게 좋은 방법이다. 스프링의 인터페이스를 사용할만한 유일한 경우는 스프링 컨테이너 안에서 특별하게 사용될 프레임워크 빈을 개발할 때뿐이다.

* Hitting the database

1) Spring의 DataAccessException

java.sql.SQLException은 checked Exception입니다. 즉, 개발자가 try-catch로 잡아줘야 합니다.

이는 코드를 난잡하게 만들수 있습니다.  그리고 SQLException이 제공하는 예외는 Spring에 비해서 매우 종류가 많지 않습니다.

 
DataAccessException은 SQLException이나 HibernateException등과 같이 특정 기술에 의존적인 예외를 던지지 않기때문에, 데이터 접근 인터페이스가 구현에 의존적인 예외가 아닌 스프링의 일반적인 DataAccessException을 던지게 함으로써, 특정한 퍼시스턴스 구현에 결합되는 일을 방지합니다.

 
DataAccessException은 RuntimeException이기 때문에 unchecked Exception에 속하기 때문에 개발자가 반드시 처리하지 않아도 됩니다. unchecked Exception이 발생하는 경우는 대개 복구가 불가능한 것이기 때문에 개발자가 직접 처리해야 할 필요는 없습니다. 만약 복구가 가능한 것이라면 예외를 잡아 호출 스택으로 전달되도록 할 수도 있습니다. (처리하고 싶으면 잡아서 처리하고, 하고 싶지 않으면 Spring에서 잡도록 내버려 둬도 됩니다.)

 
Spring의 DAO Exception 분류 체계는 매우 세밀하기 때문에, 서비스 객체가 잡고자 하는 exception의 타입과 호출 스택에 전달하고자 하는 exception을 정확히 선택할 수 있습니다.

2) Spring에서 데이터 접근

Spring은 데이터 접근 프로세스에 있어서 고정된(변하지 않는) 부분을 template(템플릿)으로 가변적인(변하는) 부분을 callback(콜백)으로 구분합니다.

template은 프로세스의 고정된 부분을 관리하는 반면, callback은 구체적인 구현을 넣어야 하는 장소입니다.

 
template은 데이터 저장소로의 연결 취득, 트랜잭션 제어, 자원반환, 예외 처리등하고싶을 일을 구현하기 위해 중복적으로 해야하는 작업들입니다.

callback 인터페이스의 구현 클래스는 질의문 생성, 파라미터 바인딩, 결과 집합 마샬링(marshalling) 등 애플리케이션에 특정적인 부분을 정의합니다.

[그림] 스프링 DAO 템플릿과 콜백 클래스의 역할 ( 차후에 추가 )

* JDBC 코드의 문제점은 무엇일까요? (Quiz)

Spring에서의 JdbcTemplate

Spring이 JDBC 프레임워크는 자원 관리와 에러 처리의 부담을 떠맡음으로써 JDBC 코드를 깨끗하게 만들어 줍니다.

 
JdbcTemplate 클래스가 작업하기 위해 필요한 것은 DataSource뿐입니다.

- JdbcTemplate과 함께 쓰이는 Class

//---------------------------------------------------------------
// 데이터 쓰기
//---------------------------------------------------------------

• PreparedStatementCreator : 이 인터페이스의 구현 클래스는 PreparedStatement를 생성시킬 책임을 갖는다.  이 인터페이스를 구현할 때에는 인자로 넘어온 Connection으로부터 PreparedStatement를 생성하고 리턴해줘야 한다. 그러나 예외 처리에 대해서는 신경쓰지 않아도 된다.
  
  

  /**
   * One of the two central callback interfaces used by the JdbcTemplate class.
   * This interface creates a PreparedStatement given a connection, provided
   * by the JdbcTemplate class. Implementations are responsible for providing
   * SQL and any necessary parameters.
   */
  public interface PreparedStatementCreator {
  
      /**
       * Create a statement in this connection. Allows implementations to use
       * PreparedStatements. The JdbcTemplate will close the created statement.
       * @param con Connection to use to create statement
       * @return a prepared statement
       * @throws SQLException there is no need to catch SQLExceptions
       * that may be thrown in the implementation of this method.
       * The JdbcTemplate class will handle them.
       */
      PreparedStatement createPreparedStatement(Connection con) throws SQLException;
  
  }
  
  

• SqlProvider : SqlProvider 인터페이스의 getSql() 이라는 하나의 메소드를 구현함으로써 클래스가 SQL 문자열을 JdbcTemplate 클래스에 제공할 수 있게 된다. 이렇게 하면  JdbcTemplate 클래스가 자신이 실행하는 모든 SQL 문장에 대해 로그를 남기는 것이 가능해진다.
  
  

  public interface SqlProvider {
  
      /**
       * Return the SQL string for this object, i.e.
       * typically the SQL used for creating statements.
       * @return the SQL string, or <code>null</code>
       */
      String getSql();
  
  }
  
  
  

• PreparedStatementSetter : PreparedStatementCreatr를 보완. 파라미터를 세팅하기만 하고 모든 예외 처리는 JdbcTemplate 클래스가 해 줄 것이다.
  
  

  public interface PreparedStatementSetter {
  
      /**
       * Set parameter values on the given PreparedStatement.
       * @param ps the PreparedStatement to invoke setter methods on
       * @throws SQLException if a SQLException is encountered
       * (i.e. there is no need to catch SQLException)
       */
      void setValues(PreparedStatement ps) throws SQLException;
  
  }
  
  
  

• BatchPreparedStatement : 갱신하고자 하는 레코드가 둘 이상일 경우.
  
  

  public interface BatchPreparedStatementSetter {
  
      /**
       * Set parameter values on the given PreparedStatement.
       * @param ps the PreparedStatement to invoke setter methods on
       * @param i index of the statement we're issuing in the batch, starting from 0
       * @throws SQLException if a SQLException is encountered
       * (i.e. there is no need to catch SQLException)
       */
      void setValues(PreparedStatement ps, int i) throws SQLException;
  
      /**
       * Return the size of the batch.
       * @return the number of statements in the batch
       */
      int getBatchSize();
  
  }
  
  
  // ------------------------------------------------------------------------------------
  //  데이터 읽기
  // ------------------------------------------------------------------------------------
  
  
  스프링을 사용하지 않은 이전의 JDBC 에서는 데이터베이스에 질의를 한 후에 ResultSet을 순환하여
  결과를 얻어내야 하는데 스프링은 그 일을 대신 해 준다.
  
  

• RowCallbackHandler

• RowMapperResultReader -> 2.x 버젼부터 RowMapperResultSetExtractor 사용
  

• CallableStatementCallback : 저장 프로시저 호출하기
  

  
  

3) DaoSupport

DaoSupport class사용시의 문제점은

MemberDaoImpl, PostDaoImpl, BoardDaoImpl 등의 class가 있다고 하면 JdbcTemplate을 이용하여 구현을 하려고 하면

JdbcTemplate을 설정하는 코드가 각각의 클래스의 Setter 메소드를 이용하여 세팅이 되야하는데, 이것을 중복을 유발합니다.

DAO 클래스마다 중복적으로 발생하는 JdbcTemplate설정을 추상화 계층으로 끌어올려 JdbcDaoSupport Class를 만들어서, Support 클래스는 데이터베이스와의 통신에 사용되는 클래스에 직접적으로 접근할 수 있도록 해줍니다.

JdbcDaoSupport클래스는 Connection 객체를 얻기 위해 getConnection() 메소드를 호출하면 됩니다.

JdbcDaoSupport 클래스를 이용하면 DataSource를 Spring 설정파일에서 매핑시켜주지 않아도 됩니다.

4) Spring의 ORM 프레임워크 지원 기능

•  lazy loading : 객체들의 관계 전체를 그대로 얻기 원하지 않을 경우 필요로 하는 데이터만 가져올 수 있도록 해줌
  
• eager fetching : ( <-> lazy loading) : 하나의 질의로 전체 객체들을 한번에 얻어오는 것
  
• caching : 주로 읽기만 하는 데이터의 경우 매번 Database에서 가져오기를 원치 않을 때 사용.
  
• cascading : 제약사항

5) Hibernate와의 연동

Hibernate에서는 SessionFactory를 이용하여 session객체를 생성하는 것이 가장 중요하고,

설정파일에서 SessionFactory를 property로 추가(DataSource)합니다.

6) Caching

Cache 설정파일을 만들고, Spring 설정파일에서 cache 설정파일이 어디있는지 설정해주고,

cache대상과 비울 대상을 메소드로 설정합니다.(XML이나 Annotation으로 설정)

스프링 프레임웍에 대한 세미나를 1회때인가, 스프링 소개와 IoC할때 가고, 정말
오랫만에 참여한지라 알아들을 수 있을 것인가, 염려와 함께 도곡역으로 향하였습니다.

장소는 도곡역 IBM 온디맨드 홀에서 열렸는데, 입구부터 백기선 님이 안내를 해주시더군요.국민대에서 할때 보다 훨씬 찾기 쉽고 더 집중이 잘 된 장소더군요^^

(차분하고, 듬직(?)하신 목소리로 너무 어렵지 않게 머릿속에 잘 들어왔습니다. )

Spring Web Flow (SWF) is an emerging module of The Spring Framework. The module is part of Spring’s web application development stack, which includes Spring MVC.

Acegi Security is a powerful, flexible security solution for enterprise software, with a particular emphasis on applications that use Spring. Using Acegi Security provides your applications with comprehensive authentication, authorization, instance-based access control, channel security and human user detection capabilities.

Spring Acegi Tutorial :
http://www.tfo-eservices.eu/wb_tutorials/media/SpringAcegiTutorial/HTML/SpringAcegiTutorial-1_1-html.html

발표시나리오 :
http://younghoe.info/663

일이 있어서 끝까지 듣지는 못하여, 정리를 하지 못했습니다.
안영회님 블로그에 올라와 있는, 그림만 보아도 Filter들이 무슨일을 벌이고 처리하는지
대략알수 있다는 무책임한 말로 후기를 끝냅니다. +_+

다음번엔 무슨 주제가 기다릴까요.. 또 가고싶습니다!ㅋㅋ
--------------------------------------------------------------------------------------------------------------------

이 글에 대한 Resource :
http://www.theserverside.com/tt/articles/article.tss?l=SpringWebFlow
http://younghoe.info/663