2012-05-29 개발일지

오늘은 트랜잭션 설정과 롤백테스트를 해봤다.

아래 세개 사이트에서 지식을 참고하고 진행했다.

우선 DisPatcherServlet에 아래와 같은 트랜잭션에 관련 설정을 추가했다.

<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="dataSource" />
</bean>

<tx:annotation-driven transaction-manager="transactionManager"/>

그리고 DAO단(persistence layer)단을 호출하는 Service단의 메서드에 @Transactional 어노테이션을 붙였다.

@Transactional(propagation = Propagation.REQUIRED, readOnly = true)
public void add(Temp temp) {
    try{
        tempDao.test();
        tempDao.test2();
    }catch(Exception e) {
        throw new RuntimeException();
    }
}

@Transactional속성으로 propagation과 readOnly를 추가했다. 트랜잭션 전파속성과 읽기속성에 관한 설정이다.

그리고 중요한 부분은 DAO단의 예외로 인해 Exception을 던졌을 때, add메서드에서 언체크예외로 던졌다는 것이다.

체크예외로 하지 않고 언체크예외로 던지게 되면 add메서드를 호출한 메서드도 따로 예외처리를 하지 않아도 되고,

가장 중요한건, 예외상황이 벌어졌을시 “롤백처리”가 가능하다는 점이다.

실제로 체크예외로 예외를 던진 결과 롤백처리가 되지 않았다. 이와 관련된 부분은 위의 링크에 포함되어 있다.

선언적 트랜잭션 관리를 위한 스프링의 기본적인 행동은 EJB convention을 따른다
즉, 롤백은 자동으로 언체크예외에서만 작동한다.

라는 점이다. 이 부분이 이번 테스트에서 건진 제일 큰 놈이다.

그리고, 테스트하면서 들었던 하나의 의문은 트랜잭션 관련 설정을 DispatcherServlet에

매핑되어 있는 xml안에 해야 트랜잭션이 적용된다는 것이다.

ContextLoaderListener의 xml에 트랜잭션 관련 설정을 넣어놓으면 트랜잭션이

적용되질 않았다. 아래 링크를 보면 DispatcherServlet과 ContextLoaderListener 각각

별도의 WebApplicationContext를 생성한다고 나오는데, 왜 ContextLoaderListener안에

트랜잭션관련 설정을 했을 땐, 트랜잭션이 적용되지 않는지 의문이다.

아~ 범균님 스프링 책을 다시 봐야겠다.

================================================================

트랜잭션이 적용되지 않는 문제는 오늘 기선님께 물어봐서 해결했다.

결국 아래 빈을 스캔하는 구문이 문제였다.

<context:component-scan base-package="com.test.*" />

저렇게 되면 트랜잭션이 적용되지 않는 Service와 Repository를 사용하게 되버려서 문제가 생긴다.

결국엔 DS와 CCL간의 컴포넌트 스캔을 다르게 설정해서 해결했다.

[DispatcherServlet]

<context:component-scan base-package="com.test.*">
    <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
    <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Service"/>
    <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Repository"/>
</context:component-scan>

[ContextLoaderListener]

<context:component-scan base-package="com.test.*">
    <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>

결국엔, 트랜잭션 설정이 있는 CCL쪽에선 Controller를 제외한 Service, Repository의 빈을 등록하고

DS에선 Service, Repository의 빈을 제외한 Controller빈을 등록해서 중복을 제거함으로서 문제를 해결했다^^ 아래 포스팅을 참고하자

Advertisements

2012-05-24 개발일지

오늘은 업무에 들어가기전 주안점을 둔 것이 예외처리쪽을 신경써서 다시 보자는 것이었다.

비록 갑자기 치고 들어온 업무가 있어 그 때는 늦게 시작했지만,

오후 늦게라도 기존에 작성했던 소스의 예외처리를 다시 체크해 볼 수 있었다.

토비의 스프링3에서는 예외처리전략을 이렇게 설명하고 있다.

================================================================

  • 예외를 처리할 때 반드시 지켜야 할 핵심 원칙은 한가지다.
    모든 예외는 적절하게 복구되든지 아니면 작업을 중단시키고 운영자 또는
    개발자에게 통보되어야 한다.

================================================================

오늘 내가 선택한 방법은 모든 예외케이스를 체크예외로 catch로 모은 다음,

예외상황에 맞는 메세지에 번호를 부여해 사용자에게 통보해주는 방식을 선택했다.

앞의 원칙에서 보자면 예외복구라고 하는 쪽이 맞을 것이다.

아무 생각없이 작성했던 예외관련한 코드도 다시 볼 수 있어 유익한 시간이었다.

더불어, 앞으로 예외관련된 코드를 작성할 시 체크예외로 잡을 수 없는 예외사항은

모두 언체크 또는 RuntimeException으로 넘겨버리자고 생각했다.

절대 무책임한 예외코드를 만들지 말자는 다짐과 함께^^

2012-05-23 개발일지

1. 요즘은 서버사이드보단 클라이언트 사이드 개발에 더 주력하고 있다.

그 말인 즉슨, 마크업수정이 많다보니 그에 따른 html과 javascript의 개선과 수정이

많다는 말이다.

javascript개발은 확실히 jquery가 많은 기능을 제공해주고 있어 그리 어렵지 않게 개발할

수 있고, 팀내 자바스크립트 표준을 만들어서 자바 개발자에겐 비교적 익숙하게

모듈화하여 개발할 수 있는 체계가 만들어져 있다.

그래서인지 자바스크립트 개발이 생각처럼 재밌어지는 요즘이기도 하다.

지금까지 경험해보지 못한 새로운 경험이자 신기한 경험이다.

================================================================

2. 무의식적으로 써온 각종 라이브러리 파일. 그리고 프로젝트간의 설정관계를

파악하려 노력중이다.

이를 파악하려면 아무래도 메이븐이란 놈과 친해져야 할 듯 싶다.

Ant도 사용해보지 않은 나로선 이런 빌드툴이 낯설긴 하지만, 뭐 처음부터 잘한 사람

없듯이 천천히 친해져보려고 한다.

어젠 서로 의존관계에 있는 프로젝트에서 jsp의 커스텀태그 내용을 가져올 때,

해당 프로젝트에서 jar로 배포된 프로젝트의 META-INF 밑의 *.tld를 검색해

커스텀태그의 내용을 가져온다는 사실을 알았다.

더불어 톰캣(WAS) 버전에 따른 JSP와 SERVLET 스펙에 맞는 커스텀태그가 지원된다는

사실 또한 알게 되었다. 해당 내용은 아래 잘 설명되어 있다.

중요한 것은 머리로만 이해해서는 온전한 내 것이 될 수 없다.

프로그래머로서의 명언 “백문이불여일타!

비단, 코드뿐만 아니라 개발환경의 설정도 이와 별반 다르진 않을 것이다.