[스프링 DB 1편] - 10. 트랜잭션 AOP / @Transactional

 

트랜잭션 AOP 이해

 

지금까지 트랜잭션을 편리하게 처리하기 위해서 트랜잭션 추상화도 도입하고,

 

추가로 반복적인 트랜잭션 로직을 해결하기 위해 트랜잭션 템플릿도 도입했다.

 

트랜잭션 템플릿 덕분에 트랜잭션을 처리하는 반복 코드는 해결할 수 있었다.

 

하지만 서비스 계층에 순수한 비즈니스 로직만 남긴다는 목표는 아직 달성하지 못했다.

 

이럴 때 스프링 AOP를 통해 프록시를 도입하면 문제를 깔끔하게 해결할 수 있다.

 

 

참고 ) 지금은 @Transactional 을 사용하면 스프링이 AOP를 사용해서 트랜잭션을 편리하게 처리해준다 정도로 이해해도 된다.

 

 

 

 

프록시를 통한 문제 해결

 

프록시 도입 전

 

프록시를 도입하기 전에는 기존처럼 서비스의 로직에서 트랜잭션을 직접 시작한다.

 

서비스에 비즈니스 로직과 트랜잭션 처리 로직이 함께 섞여있다.

 

 

프록시 도입 후

 

프록시 : 일종의 대리인이다. 대신 무언가를 처리해주는 사람이다. 

 

클라이언트가 서비스를 직접 호출하는 것이 아니라 프록시를 통해서 호출한다. 

 

프록시를 사용하면 트랜잭션을 처리하는 객체와 비즈니스 로직을 처리하는 서비스 객체를 명확하게 분리할 수 있다.

 

 

트랜잭션 프록시가 트랜잭션 처리 로직을 모두 가져간다.

 

그리고 트랜잭션을 시작한 후에 실제 서비스를 대신 호출한다.

 

트랜잭션 프록시 덕분에 서비스 계층에는 순수한 비즈니즈 로직만 남길 수 있다.

 

트랜잭션 프록시 코드

public class TransactionProxy {
    private MemberService target;
    public void logic() { 
        //트랜잭션 시작
        TransactionStatus status = transactionManager.getTransaction(..);
        try {
            //실제 대상 호출 
            target.logic();
            transactionManager.commit(status); //성공시 커밋 
        } catch (Exception e) {
            transactionManager.rollback(status); //실패시 롤백
            throw new IllegalStateException(e);
        }
    } 
}

 

 

트랜잭션 프록시가 실제 호출해야할 비즈니스 로직(target)을 내부에 갖고 있다 .

 

트랜잭션 프록시 적용 후 서비스 코드

public class Service {
    public void logic() {
//트랜잭션 관련 코드 제거, 순수 비즈니스 로직만 남음
        bizLogic(fromId, toId, money);
    }
}

 

 

스프링이 제공하는 트랜잭션 AOP

 

개발자는 트랜잭션 처리가 필요한 곳에 @Transactional 애노테이션만 붙여주면 된다.

 

스프링의 트랜잭션 AOP는 이 애노테이션을 인식해서 트랜잭션 프록시를 적용해준다.

 

 

 

@Transactional 적용 

@Transactional
public void accountTransfer(String fromId, String toId, int money) throws
        SQLException {
        bizLogic(fromId, toId, money);
        }

 

순수한 비즈니스 로직만 남기고, 트랜잭션 관련 코드는 모두 제거했다.

 

스프링이 제공하는 트랜잭션 AOP를 적용하기 위해 @Transactional 애노테이션을 추가했다.

 

 

 

 

 AOP 테스트 코드 

@SpringBootTest
class MemberServiceV3_3Test

 

@SpringBootTest : 스프링 AOP를 적용하려면 스프링 컨테이너가 필요하다.

 

이 애노테이션이 있으면 테스트시 스프링 부트를 통해 스프링 컨테이너를 생성한다.

 

@Autowired
MemberRepositoryV3 memberRepository;
@Autowired
MemberServiceV3_3 memberService;

 

그리고 테스트에서 @Autowired 등을 통해 스프링 컨테이너가 관리하는 빈들을 사용할 수 있다.

 

 

@TestConfiguration
static class TestConfig {
   @Bean
   DataSource dataSource() {
      return new DriverManagerDataSource(URL, USERNAME, PASSWORD);
   }
   @Bean
   PlatformTransactionManager transactionManager() {
      return new DataSourceTransactionManager(dataSource());
   }
   @Bean
   MemberRepositoryV3 memberRepositoryV3() {
      return new MemberRepositoryV3(dataSource());
   }
   @Bean
   MemberServiceV3_3 memberServiceV3_3() {
      return new MemberServiceV3_3(memberRepositoryV3());
   }
}

 

@TestConfiguration : 테스트 안에서 내부 설정 클래스를 만들어서 사용하면서 이 에노테이션을 붙이면,

 

스프링 부트가 자동으로 만들어주는 빈들에 추가로 필요한 스프링 빈들을 등록하고 테스트를 수행할 수 있다.

 

DataSource 스프링에서 기본으로 사용할 데이터소스를 스프링 빈으로 등록한다.

 

추가로 트랜잭션 매니저에서도 사용한다.

DataSourceTransactionManager 트랜잭션 매니저를 스프링 빈으로 등록한다.

 

스프링이 제공하는 트랜잭션 AOP는 스프링 빈에 등록된 트랜잭션 매니저를 찾아서 사용하기 때문에

 

트랜잭션 매니저를 스프링 빈으로 등록해두어야 한다.

 

 

 

 

트랜잭션 AOP 적용 전체 흐름

 

 

0. AOP 프록시 생성 : @Transactional 어노테이션이 있는 메서드는 스프링이 트랜잭션을 적용하는 프록시를 만듦 

 

AOP 프록시에서 트랜잭션 로직을 다 처리해준다. 실제 서비스도 대신 호출해준다. 

 

 

1. 클라이언트 서비스 호출 : 직접 호출하는 것이 아닌 프록시를 통해 호출

 

2. 스프링 컨테이너를 통해 트랜잭션 매니저 획득 

 

3. 트랜잭션 매니저를 통해서 트랜잭션을 시작한다. 

 

4. 데이터소스를 가지고 커넥션을 생성 

 

5. con.setAutoCommit(false) / 수동 커밋 모드 설정 

 

6-7. 커넥션 동기화 : 트랜잭션 동기화 매니저에 커넥션을 보관 

 

8. 프록시에서 실제 서비스를 호출 

 

9. 서비스 비즈니스 로직이 수행 ->  리포지토리 호출 

 

리포지토리에서는 트랜잭션 동기화 매니저에 보관된 커넥션을 꺼내서 데이터 접근 로직을 수행

 

10. 성공 -> commit   /   예외 -> rollback

 

 

 

 

정리

 

스프링이 제공하는 선언적 트랜잭션 관리 덕분에 드디어 트랜잭션 관련 코드를 순수한 비즈니스 로직에서 제거할 수 있었다.

개발자는 트랜잭션이 필요한 곳에 @Transactional 애노테이션 하나만 추가하면 된다.

 

나머지는 스프링 트랜잭션 AOP가 자동으로 처리해준다.

 

전체 구조를 이해하는데 초점을 맞추자.

 

 

 

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-db-1/dashboard

스프링 DB 1편 - 데이터 접근 핵심 원리 - 인프런 | 강의