6. 트랜잭션 처리 : 스프링 AOP Advisor 사용

스프링에서는 트랜잭션 관련 설정을 앞에서 살펴본 AOP로 처리합니다. 그리고 추가로 트랜잭션을 제어하는 어드바이스를 설정하기 위해 스프링 설정 파일에 트랜잭션 관련 네임스페이스도 추가해야 합니다.

 

1. 트랜잭션 네임스페이스 등록 : Namespace에서 tx를 추가

 

 

 

2. 트랜잭션 관리자 등록 : 스프링 설정 파일에 DataSourceTransactionManager 클래스를 <bean> 등록합니다.

이는 현재 우리가 가지고 잇는 두 개의 DAO 클래스가 모두 JDBC를 기반으로 동작하기 때문이데, 스프링은 어떤 기술을 이용하여 데이터베이스 연동을 처리햇느냐에 따라 트랜잭션 관리자가 달라집니다.

 

추후 Mybatis나 JPA를 이용하여 DAO 클래스를 추가로 구현 할 것이고, 당연히 그때 트랜잭션 관리자를 변경하게 될 것입니다. ( 예시) JPA : JPATransactionManager )

 

 

트랜잭션 어드바이스도 함께 설정하도록 합니다. 이때 read-only="true" 설정은 읽기 전용으로 처리되어 트랜잭션 관리 대상에서 제외한다는 의미입니다. 참고로 롤백 여부도 속성을 통해 지정 가능합니다.

 

 

 

3. AOP Aspect 앨리먼트 등록

지금까지 트랜잭션 관리 어드바이스 <aop:advisor> 까지의 설정했으니, 비즈니스 메소드 실행 후에 트랜잭션 관리 어드바이스가 동작하도록 AOP 설정만 추가하면 됩니다.

 

이때 <aop:aspect> 앨리먼트를 사용하지 않고 <aop:advisor> 앨리먼트를 사용한다는 점이 기존 AOP설정과는 다릅니다. (우리는 앞에서 포인트컷과 어드바이스를 결합할 때 <aop:aspect> 앨리먼트를 사용했었다)

그 이유는, <aop:aspect>를 사용하려면 포인트컷과 결합할 advice 객체의 id와 method name을 알아야만 <aop:aspect>를 이용하여 설정할 수 있기 때문입니다. 그러나 우리는 트랙잭션 관리 어드바이스를 직접 클래스 구현한게 아니라 <tx:advice>설정을 통해 스프링 컨테이너가 자동으로 생성했으므로 method name을 알 수 없기에 결국 <aop:aspect> 사용이 불가한 것입니다.

 

<aop:advisor>와 <aop:aspect>는 같은 기능의 앨리먼트 이므로 txPointcut으로 지정한 메소드가 호출될 때, txAdvice로 등록한 어드바이스가 동작하여 트랜잭션을 관리하도록 설정하면 됩니다.

 

 

 

 

 

4. 테스트

 

 

이렇게 실행 할 경우 insertBoard() 기능이 실행되었다는 로그는 2번 찍히게 되지만, 그 아래에 pk에 해당하는 seq가 중복되기 때문에 무결성 제약 조건 에러가 출력됩니다.

 

 

트랜잭션에 의해 롤백되므로(스프링 트랜잭션 관리자를 상속하는 인터페이스(PlatformTransactionManager)는 commit과 rollback 메소드를 가지고있음) select문을 통해 조회해볼 경우 글 목록에 변화가 없음을 알 수 있습니다.