[스프링 DB 1편] 스프링과 문제 해결 - 트랜잭션

애플리케이션 구조

다양한 애플리케이션 구조가 있지만 가장 단순하면서 많이 사용하는 방법은 아래의 3계층으로 나누는 것이다.

프리젠테이션 계층 => 서비스 계층 => 데이터 접근 계층 => DB 서버

프레젠테이션 계층
- UI와 관련된 처리 담당
- 웹 요청과 응답
- 사용자 요청을 검증
- 주 사용 기술
  - 서블릿과 HTTP 같은 웹 기술
  - 스프링 MVC
서비스 계층
- 비즈니스 로직을 담당
- 주 사용 기술
  - 가급적 특정 기술에 의존하지 않고, 순수 자바 코드로 작성
데이터 접근 계층
- 실제 데이터베이스에 접근하는 코드
- 주 사용 기술
  - JDBC
  - JPA
  - File
  - Redis
  - Mongo

가장 중요한 계층

가장 중요한 계층은 핵심 비즈니스 로직이 들어있는 서비스 계층이다.

시간이 흐르며 해당 애플리케이션에 변화가 생길 수도 있다.
JSP를 Thymeleaf로 바꾸고, MyBatis를 JPA로 바꿔도
비즈니스 로직은 최대한 변경없이 유지되어야 한다.

그러려면 서비스 계층을 특정 기술에 종속적이지 않게 개발해야 한다. 왜냐하면 계층을 나눈 것도 서비스 계층을 최대한 순수하게 유지하기 위해서다.
기술에 종속적인 부분은 이미 프레젠테이션 계층, 데이터 접근 계층에서 가지고 간다.

서비스 계층이 특정 기술에 종속되지 않기 때문에 비즈니스 로직을 유지보수 하기도 쉽고, 테스트 하기도 쉽다. 즉, 서비스 계층은 가급적 비즈니스 로직만 구현하고 특정 구현 기술에 직접 의존해서는 안된다.
이렇게 하면 향후 구현 기술이 변경될 때 변경의 영향 범위를 최소화 할 수 있다.

문제점들

기존 서비스 살펴보기 (MemberServiceV1)

MemberServiceV1 은 특정 기술에 종속적이지 않고, 순수한 비즈니스 로직만 존재한다.
특정 기술과 관련된 코드가 거의 없어서 코드가 깔끔하고, 유지보수 하기 쉽다.
향후 비즈니스 로직의 변경이 필요하면 이 부분을 변경하면 된다.
하지만 SQLException이라는 JDBC 기술에 의존한다는 점이 존재한다.
- 이 부분은 memberRepository에서 올라오는 예외이기 때문에 memberRepository에서 해결해야 한다.
또한 MemberRepositoryV1이라는 구체 클래스에 의존하고 있다.
- 의존도를 줄이기 위해서는 추후에 인터페이스를 도입해야 한다.

기존 서비스 살펴보기 (MemberServiceV2)

트랜잭션을 사용하기 위해서 JDBC 기술에 의존해야 한다.
- javax.sql.DataSource
- java.sql.Connection
- java.sql.SQLException
게다가 비즈니스 로직보다 JDBC를 사용해서 트랙잭션을 처리하는 코드가 더 많다.
- 트랜잭션을 사용하기 위해 JDBC 기술에 의존하다보니 생기는 문제점이다.
- 이렇게 되면 다른 기술로 바꾸면 관련 서비스 코드도 모두 함께 변경해야 한다.
핵심 비즈니스 로직과 JDBC 기술이 섞여 있어서 유지보수 하기 어렵다.

결국 핵심은 뭘까?

현재까지 개발한 애플리케이션에서 보이는 문제점은 3가지이다.
문제점
- 트랜잭션 문제
- 예외 누수 문제
- JDBC 반복 문제

문제점 - 트랜잭션 문제

가장 큰 문제인 트랜잭션을 적용하면서 생긴 문제들이다.

JDBC 구현 기술이 서비스 계층에 누수되는 문제
- 트랜잭션을 적용하기 위해 JDBC 구현 기술이 서비스 계층에 누수되었다.
  - 섞였다는 뜻으로 이해하면 된다.
- 서비스 계층은 순수해야 한다.
  - 구현 기술을 변경해도 변화에 대응하기 위해 서비스 계층 코드는 최대한 유지할 수 있어야 한다.
  - 데이터 접근 계층에 JDBC 코드를 다 몰아두는 이유가 그래서다.
  - 물론 데이터 접근 계층의 구현 기술이 변경될 수도 있으니 데이터 접근 계층은 인터페이스를 제공하는 것이 좋다.
- 서비스 계층은 특정 기술에 종속되지 않아야 한다.
  - 데이터 접근 계층으로 JDBC 관련 코드를 모았는데, 트랜잭션을 적용하면서 결국 서비스 계층에 JDBC 구현 기술의 누수가 발생했다.
트랜잭션 동기화 문제
- 같은 트랜잭션을 유지하기 위해 커넥션을 파라미터로 넘겨야 한다.
- 똑같은 기능도 트랜잭션용 기능과 트랜잭션을 유지하지 않아도 되는 기능으로 분리해야 한다.
트랜잭션 적용 반복 문제
- 트랜잭션 적용하기 위해 작성되는 반복되는 코드가 많다.
- try-catch-finally

문제점 - 예외 누수

데이터 접근 계층의 JDBC 구현 기술 예외가 서비스 계층으로 전파된다.
SQLException은 체크 예외다.
- 데이터 접근 계층을 호출한 서비스 계층에서 해당 예외를 잡아서 처리하거나 명시적으로 throws를 통해서 다시 밖으로 던져야한다.
SQLException 은 JDBC 전용 기술이다.
- 향후 JPA나 다른 데이터 접근 기술을 사용하면, 그에 맞는 다른 예외로 변경해야 하고, 결국 서비스 코드도 수정해야 한다.

문제점 - JDBC 반복 문제

MemberRepository 코드는 순수한 JDBC를 사용했다.
이 코드들은 유사한 코드의 반복이 너무 많다.
- try-catch-finally

스프링과 문제 해결

스프링은 서비스 계층을 순수하게 유지하면서,
지금까지 이야기한 문제들을 해결할 수 있는 다양한 방법과 기술들을 제공한다.

트랜잭션 추상화

구현 기술에 따른 트랙잭션 사용법

트랜잭션은 원자적 단위의 비즈니스 로직을 처리하기 위해 사용한다.
구현 기술마다 트랜잭션을 사용하는 방법이 다르다.
- JDBC
  - con.setAutoCommit(false)
- JPA
  - transaction.begin()
이런 상황에서 데이터 접근 기술을 바꾸게 되면 서비스 계층의 트랜잭션을 처리하는 코드도 모두 함께 변경해야 한다.

트랜잭션 추상화

그래서 JDBC를 구현한 JDBC 드라이버처럼 인터페이스를 구현하도록 개선되었다.
우리는 트랜잭션을 추상화한 인터페이스인 TxManager의 구현체를 사용하면 된다.

public interface TxManager {
    begin();
    commit();
    rollback();
}

그래서 TxManager 인터페이스에 사용 중인 기술 종류에 따라서
JDBC 트랜잭션 기능을 제공하는 구현체인 JdbcTxManager나
JPA 트랜잭션 기능을 제공하는 구현체인 JpaTxManager를 의존성 주입을 하면 된다.

클라이언트인 서비스는 인터페이스에 의존하고 DI를 사용한 덕분에 OCP 원칙을 지키게 되었다.
이제 트랜잭션을 사용하는 서비스 코드를 전혀 변경하지 않고, 트랜잭션 기술을 마음껏 변경할 수 있다.

스프링의 트랜잭션 추상화

스프링은 이미 이런 고민을 다 해두었다.
우리는 스프링이 제공하는 트랜잭션 추상화 기술을 사용하면 된다.

스프링은 스프링 트랜잭션 추상화 인터페이스인 PlatformTransactionManager을 제공한다.
데이터 접근 기술에 따른 트랜잭션 구현체도 대부분 만들어두어서 가져다 사용하기만 하면 된다.
PlatformTransactionManager 인터페이스와 구현체를 포함해서 트랜잭션 매니저라고 표현한다.

package org.springframework.transaction;

public interface PlatformTransactionManager extends TransactionManager {
    TransactionStatus getTransaction(@Nullable TransactionDefinition definition) throws TransactionException;
    void commit(TransactionStatus status) throws TransactionException;
    void rollback(TransactionStatus status) throws TransactionException;
}

구현체 종류
- JDBC 트랜잭션 관리
  - DataSourceTransactionManager
  - 스프링 5.3부터 DataSourceTransactionManager를 상속받은 JdbcTransactionManager를 제공한다.
  - 그런데 막상 DataSourceTransactionManager과 JdbcTransactionManager의 기능은 크게 차이 나지 않는다.
- JPA 트랜잭션 관리
  - JpaTransactionManager
- 하이버네이트 트랜잭션 관리
  - HibernateTransactionManager

트랜잭션 동기화

스프링이 제공하는 트랜잭션 매니저는 크게 2가지 역할을 한다. - 트랜잭션 추상화 - 리소스 동기화

트랜잭션 추상화

앞서 설명한 트랜잭션 추상화와 같은 내용이다.

리소스 동기화

트랜잭션을 유지하려면 트랜잭션의 시작부터 끝까지 같은 데이터베이스 커넥션을 유지해야한다.
결국 같은 커넥션을 동기화하기 위해서 이전(MemberServiceV2)에는 파라미터로 커넥션을 전달하는 방법을 사용했다.
파라미터로 커넥션을 전달하는 방법은 코드가 지저분해질 뿐만 아니라
커넥션을 넘기는 메서드와 넘기지 않는 메서드를 중복해서 만들어야 하는 등 여러가지 단점들이 많다.

트랜잭션 동기화 매니저

스프링은 트랜잭션 동기화 매니저를 제공한다.
이것은 쓰레드 로컬(ThreadLocal)을 사용해서 커넥션을 동기화해준다.
트랜잭션 매니저는 내부에서 이 트랜잭션 동기화 매니저를 사용한다.
트랜잭션 동기화 매니저는 쓰레드 로컬을 사용하기 때문에 멀티쓰레드 상황에 안전하게 커넥션을 동기화 할 수 있다.
따라서 커넥션이 필요하면 트랜잭션 동기화 매니저를 통해 커넥션을 획득하면 된다.
따라서 이전처럼 파라미터로 커넥션을 전달하지 않아도 된다.

트랜잭션 동기화 매니저의 동작 원리

트랜잭션을 시작하려면 커넥션이 필요하다.
- 트랜잭션 매니저는 데이터소스를 통해 커넥션을 만들고 트랜잭션을 시작한다.
트랜잭션 매니저는 트랜잭션이 시작된 커넥션을 트랜잭션 동기화 매니저에 보관한다.
리포지토리는 트랜잭션 동기화 매니저에 보관된 커넥션을 꺼내서 사용한다.
- 그래서 파라미터로 커넥션을 전달하지 않아도 된다.
트랜잭션이 종료되면 트랜잭션 매니저는 트랜잭션 동기화 매니저에 보관된 커넥션을 통해
트랜잭션을 종료하고, 커넥션도 닫는다.

트랜잭션 문제 해결 - 트랜잭션 매니저1

애플리케이션에 트랜잭션 매니저를 적용해보자.

리포지토리

package hello.jdbc.repository;

import hello.jdbc.domain.Member;
import lombok.extern.slf4j.Slf4j;
import org.springframework.jdbc.datasource.DataSourceUtils;
import org.springframework.jdbc.support.JdbcUtils;
import javax.sql.DataSource;
import java.sql.*;
import java.util.NoSuchElementException;

/**
 * 트랜잭션 - 트랜잭션 매니저
 * DataSourceUtils.getConnection()
 * DataSourceUtils.releaseConnection()
 */
@Slf4j
public class MemberRepositoryV3 {
    private final DataSource dataSource;

    public MemberRepositoryV3(DataSource dataSource) {
        this.dataSource = dataSource;
    }

    //회원 정보 저장하기
    public Member save(Member member) throws SQLException {
        String sql = "insert into member(member_id, money) values(?, ?)";
        Connection con = null;
        PreparedStatement pstmt = null;
        
        try {
            con = getConnection();
            pstmt = con.prepareStatement(sql);
            pstmt.setString(1, member.getMemberId());
            pstmt.setInt(2, member.getMoney());
            pstmt.executeUpdate();
            return member;
        } catch (SQLException e) {
            log.error("db error", e);
            throw e;
        } finally {
            close(con, pstmt, null);
        }
    }

    //회원 정보 조회하기
    public Member findById(String memberId) throws SQLException {
        String sql = "select * from member where member_id = ?";
        Connection con = null;
        PreparedStatement pstmt = null;
        ResultSet rs = null;
        
        try {
            con = getConnection();
            pstmt = con.prepareStatement(sql);
            pstmt.setString(1, memberId);
            rs = pstmt.executeQuery();
            if (rs.next()) {
                Member member = new Member();
                member.setMemberId(rs.getString("member_id"));
                member.setMoney(rs.getInt("money"));
                return member;
            } else {
                throw new NoSuchElementException("member not found memberId=" + memberId);
            }
        } catch (SQLException e) {
            log.error("db error", e);
            throw e;
        } finally {
            close(con, pstmt, rs);
        }
    }

    //회원 정보 수정하기
    public void update(String memberId, int money) throws SQLException {
        String sql = "update member set money=? where member_id=?";
        Connection con = null;
        PreparedStatement pstmt = null;
        
        try {
            con = getConnection();
            pstmt = con.prepareStatement(sql);
            pstmt.setInt(1, money);
            pstmt.setString(2, memberId);
            pstmt.executeUpdate();
        } catch (SQLException e) {
            log.error("db error", e);
            throw e;
        } finally {
            close(con, pstmt, null);
        }
    }

    //회원 정보 삭제하기
    public void delete(String memberId) throws SQLException {
        String sql = "delete from member where member_id=?";
        Connection con = null;
        PreparedStatement pstmt = null;
        
        try {
            con = getConnection();
            pstmt = con.prepareStatement(sql);
            pstmt.setString(1, memberId);
            pstmt.executeUpdate();
        } catch (SQLException e) {
            log.error("db error", e);
            throw e;
        } finally {
            close(con, pstmt, null);
        }
    }

    //리소스 반납히기
    private void close(Connection con, Statement stmt, ResultSet rs) {
        JdbcUtils.closeResultSet(rs);
        JdbcUtils.closeStatement(stmt);
        //주의! 트랜잭션 동기화를 사용하려면 DataSourceUtils를 사용해야 한다.
        DataSourceUtils.releaseConnection(con, dataSource);
    }
    
    //커넥션 가져오기
    private Connection getConnection() throws SQLException {
        //주의! 트랜잭션 동기화를 사용하려면 DataSourceUtils를 사용해야 한다.
        Connection con = DataSourceUtils.getConnection(dataSource);
        log.info("get connection={} class={}", con, con.getClass());
        return con;
    }
}

MemberRepositoryV2와의 차이점을 확인해보자.

우선 DB 커넥션을 파라미터로 넘기던 부분이 모두 사라졌다.
커넥션을 트랜잭션 동기화 매니저로 관리하기 때문에 DB 커넥션을 넘겨줄 필요가 없어졌다.

DB 커넥션을 가져오는 방법이 변경됬다.
기존에는 주입받은 DataSource에서 getConnection()으로 DB 커넥션을 직접 가져왔었다.
이제는 DataSourceUtils.getConnection(dataSource)으로로 DB 커넥션을 가져온다.
DataSourceUtils.getConnection()을 사용하면 트랜잭션 매니저가 관리하는 DB 커넥션을 가져온다.
물론 관리하는 DB 커넥션이 있을 때 해당 커넥션을 바로 반환하고, 없을 때는 생성해서 반환한다.

DB 커넥션을 반환하는 방법도 변경됬다.
기존에는 JdbcUtils.closeConnection(con)을 통해 DB 커넥션을 반납했었다.
이제는 DataSourceUtils.releaseConnection(con, dataSource)을 통해 DB 커넥션을 반납한다.
이렇게 하면 트랜잭션을 사용하기 위해 동기화된 커넥션은 커넥션을 닫지 않고 그대로 유지해준다.
만약 트랜잭션 동기화 매니저가 관리하는 커넥션이 없는 경우에는 해당 커넥션을 닫는다.

서비스

트랜잭션 매니저를 사용하는 서비스를 만들어보자.

package hello.jdbc.service;

import hello.jdbc.domain.Member;
import hello.jdbc.repository.MemberRepositoryV3;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.transaction.PlatformTransactionManager;
import org.springframework.transaction.TransactionStatus;
import org.springframework.transaction.support.DefaultTransactionDefinition;
import java.sql.SQLException;

/**
 * 트랜잭션 - 트랜잭션 매니저
 */
@Slf4j
@RequiredArgsConstructor
public class MemberServiceV3_1 {
    private final PlatformTransactionManager transactionManager;
    private final MemberRepositoryV3 memberRepository;

    //계좌이체
    public void accountTransfer(String fromId, String toId, int money) throws SQLException {
        //트랜잭션 시작
        TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());

        try {
            bizLogic(fromId, toId, money); //비즈니스 로직
            transactionManager.commit(status); //성공시 커밋
        } catch (Exception e) {
            transactionManager.rollback(status); //실패시 롤백
            throw new IllegalStateException(e);
        }
    }

    //비즈니스 로직
    private void bizLogic(String fromId, String toId, int money) throws SQLException {
        Member fromMember = memberRepository.findById(fromId); //송금자
        Member toMember = memberRepository.findById(toId);//수금자

        memberRepository.update(fromId, fromMember.getMoney() - money); //송금자의 잔고 감소
        validation(toMember); //유효성 검증
        memberRepository.update(toId, toMember.getMoney() + money); //수금자의 잔고 증가
    }

    //유효성 검증
    private void validation(Member toMember) {
        if (toMember.getMemberId().equals("ex")) {
            throw new IllegalStateException("이체중 예외 발생");
        }
    }
}

MemberServiceV2와의 차이점을 확인해보자.

우선 트랜잭션을 시작하는 방식이 바뀌었다.
기존에는 DataSource에서 직접 DB 커넥션을 가져와서 con.setAutoCommit(false)으로 트랜잭션을 시작했다.
이제는 PlatformTransactionManager 인터페이스에 구현체를 주입받아서
TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition())를 통해 트랜잭션을 시작한다.
현재는 JDBC를 사용하기 때문에 DataSourceTransactionManager를 주입하지만,
만약 JPA로 사용하는 기술이 변경된다면 JpaTransactionManager를 주입하면 된다.

그리고 DB 커넥션을 반납하는 코드가 사라졌다.
이제 트랜잭션 동기화 매니저를 통해 DB 커넥션을 관리하기 때문에
순수하게 데이터 접근 계층에서 DB 커넥션을 반납하게 할 수 있다.

테스트

이제 테스트를 만들어보자.
MemberServiceV2Test를 복사해서 MemberServiceV3_1Test를 만들자.
그런 다음에 before()만 변경하자.

@BeforeEach
void before() {
    DriverManagerDataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);
    PlatformTransactionManager transactionManager = new DataSourceTransactionManager(dataSource);
    memberRepository = new MemberRepositoryV3(dataSource);
    memberService = new MemberServiceV3_1(transactionManager, memberRepository);
}

테스트해보면 모든 테스트 결과가 정상 동작하는 것을 확인할 수 있다.

트랜잭션 문제 해결 - 트랜잭션 매니저2

트랜잭션 매니저의 동작 흐름

서비스 계층에서 transactionManager.getTransaction()을 호출해서 트랜잭션을 시작한다.
트랜잭션을 시작하려면 먼저 데이터베이스 커넥션이 필요하다.
- 트랜잭션 매니저는 내부에서 데이터소스를 사용해서 커넥션을 생성한다.
커넥션을 수동 커밋 모드로 변경해서 실제 데이터베이스 트랜잭션을 시작한다.
커넥션을 트랜잭션 동기화 매니저에 보관한다.
트랜잭션 동기화 매니저는 쓰레드 로컬에 커넥션을 보관한다.
- 따라서 멀티 쓰레드 환경에 안전하게 커넥션을 보관할 수 있다.
서비스는 비즈니스 로직을 실행하면서 리포지토리의 메서드들을 호출한다.
- 이 때 커넥션을 파라미터로 전달하지 않는다.
리포지토리 메서드들은 트랜잭션이 시작된 커넥션이 필요하다.
- 리포지토리는 DataSourceUtils.getConnection()을 사용해서
  트랜잭션 동기화 매니저에 보관된 커넥션을 꺼내서 사용한다.
- 이 과정을 통해서 자연스럽게 같은 커넥션을 사용하고, 트랜잭션도 유지된다.
획득한 커넥션을 사용해서 SQL을 데이터베이스에 전달해서 실행한다.
비즈니스 로직이 끝나고 트랜잭션을 종료한다.
- 트랜잭션은 커밋하거나 롤백하면 종료된다.
트랜잭션을 종료하려면 동기화된 커넥션이 필요하다.
- 트랜잭션 동기화 매니저를 통해 동기화된 커넥션을 획득한다.
획득한 커넥션을 통해 데이터베이스에 트랜잭션을 커밋하거나 롤백한다.
전체 리소스를 정리한다.
- 트랜잭션 동기화 매니저를 정리한다.
  - 특히 쓰레드 로컬은 사용후 꼭 정리해야 한다.
- con.setAutoCommit(true)로 되돌린다.
  - 커넥션 풀을 고려하기 위해서 자동 커밋 모드를 활성화한다.
- con.close()를 호출해셔 커넥션을 종료한다.
  - 커넥션 풀을 사용하는 경우 con.close()를 호출하면 커넥션 풀에 반환된다.

트랜잭션 문제 해결 - 트랜잭션 템플릿

반복되는 코드

여태까지 개발한 서비스의 코드들을 확인해보면 반복되는 코드가 존재한다.

트랜잭션을 시작한다.
비즈니스 로직을 실행한다.
성공하면 커밋하고, 예외가 발생하면 롤백한다.

이러한 형태는 각각의 서비스에서 동일하게 반복되는데,
여기서 달라지는 부분은 비즈니스 로직뿐이다.
이럴 때 템플릿 콜백 패턴을 활용하면 이러한 반복 문제를 해결할 수 있다.

TransactionTemplate

스프링이 제공하는 TransactionTemplate 클래스를 통해 반복되는 코드를 해결해보자.

public class TransactionTemplate {
    private PlatformTransactionManager transactionManager;
    public <T> T execute(TransactionCallback<T> action){..}
    void executeWithoutResult(Consumer<TransactionStatus> action){..}
}

execute()
- 응답 값이 있을 때 사용한다.
executeWithoutResult()
- 응답 값이 없을 때 사용한다.

서비스

TransactionTemplate 클래스를 통해 아까 만들었던 MemberServiceV3_1을 개선해보자.
MemberServiceV3_1을 복사해서 MemberServiceV3_2를 만들자.

우선 MemberServiceV3_1에서는 아래와 같은 부분이 있었다.

private final PlatformTransactionManager transactionManager;
private final MemberRepositoryV3 memberRepository;

//계좌이체
public void accountTransfer(String fromId, String toId, int money) throws SQLException {
    //트랜잭션 시작
    TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());

    try {
        bizLogic(fromId, toId, money); //비즈니스 로직
        transactionManager.commit(status); //성공시 커밋
    } catch (Exception e) {
        transactionManager.rollback(status); //실패시 롤백
        throw new IllegalStateException(e);
    }
}

이제 MemberServiceV3_2에서는 아래와 같이 바꾸면 된다.

private final TransactionTemplate txTemplate;
private final MemberRepositoryV3 memberRepository;

public MemberServiceV3_2(PlatformTransactionManager transactionManager, MemberRepositoryV3 memberRepository) {
    this.txTemplate = new TransactionTemplate(transactionManager);
    this.memberRepository = memberRepository;
}

//계좌이체
public void accountTransfer(String fromId, String toId, int money) throws SQLException {
    txTemplate.executeWithoutResult((status) -> {
        try {
            bizLogic(fromId, toId, money); //비즈니스 로직
        } catch (SQLException e) {
            throw new IllegalStateException(e);
        }
    });
}

생성자 주입을 통해 TransactionTemplate을 생성했다.
그리고 executeWithoutResult 메소드를 통해 람다로 내부에서 실행될 비즈니스 로직만 명시해주었다.
TransactionTemplate은 내부의 비즈니스 로직이 정상 수행되면 커밋을,
예외가 발생하면 롤백을 하는 기본 동작을 갖고 있다.
이를 통해 우리는 반복되는 코드를 많이 줄일 수 있게 되었다.

테스트

MemberServiceV3_1Test를 복사해서 MemberServiceV3_2Test를 만들자.
MemberServiceV3_1만 MemberServiceV3_2로 바꾸면 끝이다.
그런 다음에 테스트를 실행해보면 테스트 결과가 정상인 것을 확인할 수 있다.

트랜잭션 문제 해결 - 트랜잭션 AOP 이해

TransactionTemplate을 통해 반복되는 코드 자체는 많이 줄였다.
하지만 서비스 계층에 순수하게 비즈니스 로직만 남기지는 못 했다.
이럴 때 스프링 AOP를 통해 프록시를 도입하면 문제를 해결할 수 있다.

프록시를 도입하기 전에는
클라이언트가 서비스를 호출하게 되면
서비스 내부에서 트랙잭션이 시작되고,
서비스가 리포지토리를 호출하고,
서비스 내부에서 트랜잭션이 종료되는 구조였다.

프록시를 도입하게 되면
클라이언트가 서비스를 호출하게 되면
트랜잭션 프록시를 호출해서
프록시 내부에서 트랜잭션이 시작되고,
프록시가 실제 서비스를 호출하고,
서비스가 리포지토리를 호출하고,
프록시 내부에서 트랜잭션이 종료되는 구조로 바뀐다.

그래서 프록시를 도입하면 결과적으로 서비스 계층에는 순수하게 비즈니스 로직만 남기게 할 수 있다.

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

스프링이 제공하는 AOP 기능을 사용하면 프록시를 매우 편리하게 적용할 수 있다.
- @Aspect, @Advice, @Pointcut같은 애노테이션을 사용하면 트랜잭션을 위한 AOP를 만들 수 있다.
스프링 AOP를 직접 사용해서 트랜잭션을 처리해도 되긴 하다.
- 그런데 트랜잭션은 매우 중요한 기능이고, 전세계 누구나 다 사용하는 기능이다.
- 그래서 스프링은 트랜잭션 AOP를 처리하기 위한 모든 기능을 제공한다.
  - 스프링 부트를 사용하면 트랜잭션 AOP를 처리하기 위해 필요한 스프링 빈들도 자동으로 등록해준다.
개발자는 트랜잭션 처리가 필요한 곳에 그저 @Transactional 애노테이션만 붙여주면 된다.
- 스프링의 트랜잭션 AOP는 이 애노테이션을 인식해서 트랜잭션 프록시를 적용해준다.

트랜잭션 문제 해결 - 트랜잭션 AOP 적용

이제 @Transactional 애노테이션을 통해 트랜잭션 AOP를 사용하는 서비스를 만들어보자.
MemberServiceV3_2을 복사해서 MemberServiceV3_3을 만들자.

우선 MemberServiceV3_2에서는 아래와 같은 부분이 있었다.

private final TransactionTemplate txTemplate;
private final MemberRepositoryV3 memberRepository;

public MemberServiceV3_2(PlatformTransactionManager transactionManager, MemberRepositoryV3 memberRepository) {
    this.txTemplate = new TransactionTemplate(transactionManager);
    this.memberRepository = memberRepository;
}

//계좌이체
public void accountTransfer(String fromId, String toId, int money) throws SQLException {
    txTemplate.executeWithoutResult((status) -> {
        try {
            bizLogic(fromId, toId, money); //비즈니스 로직
        } catch (SQLException e) {
            throw new IllegalStateException(e);
        }
    });
}

이제 MemberServiceV3_3에서는 아래와 같이 바꾸면 된다.

private final MemberRepositoryV3 memberRepository;

//계좌이체
@Transactional
public void accountTransfer(String fromId, String toId, int money) throws SQLException {
    bizLogic(fromId, toId, money); //비즈니스 로직
}

놀랍게도 엄청나게 코드가 줄어버렸다.
그저 @Transactional 애노테이션을 붙여줬을 뿐인데 코드가 엄청나게 단축되었다.

참고로 생성자 주입이 없어진 것은 클래스에 @RequiredArgsConstructor 추가해줬다.

아무튼 우리는 기술의 발전으로 인해 트랜잭션을 쉽게 관리할 수 있게 되었다.
그저 선배 개발자들에게 감사할 따름이다.

테스트

MemberServiceV3_2Test를 복사해서 MemberServiceV3_3Test를 만들자.
그리고 아래의 순서대로 진행하자.
1. @Slf4j 애노테이션과 @SpringBootTest 애노테이션을 클래스에 추가하기
2. MemberServiceV3_2를 MemberServiceV3_3로 바꾸기
3. before() 메소드 제거하기
4. PlatformTransactionManager를 사용하는 부분 없애기
5. MemberRepositoryV3와 MemberServiceV3_3에 @Autowired 애노테이션 추가하기
6. 마지막으로 아래의 코드를 추가해주자.

    @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());
        }
    }
    @Test
    @DisplayName("AOP 동작 여부 확인")
    void AopCheck() {
        log.info("memberService class={}", memberService.getClass());
        log.info("memberRepository class={}", memberRepository.getClass());
        Assertions.assertThat(AopUtils.isAopProxy(memberService)).isTrue();
        Assertions.assertThat(AopUtils.isAopProxy(memberRepository)).isFalse();
    }

그런 다음에 테스트를 실행해보면 테스트 결과가 정상인 것을 확인할 수 있다.
- @SpringBootTest 애노테이션이 있어야지 테스트할 때도 스프링 부트를 통해 스프링 컨테이너를 생성한다.
  - 스프링 AOP를 적용하려면 스프링 컨테이너가 필요하기 때문이다.
- AopCheck는 AOP 동작 여부를 확인하기 위해 만든 테스트 메소드다.
- @TestConfiguration 애노테이션을 통해 테스트 시 사용할 클래스들을 빈으로 등록해줬다.

트랜잭션 문제 해결 - 트랜잭션 AOP 정리

트랜잭션 AOP가 사용된 전체 흐름을 그림으로 정리하면 아래와 같이 정리할 수 있다.

선언적 트랜잭션 관리 (Declarative Transaction Management)

@Transactional 애노테이션 하나만 선언해서 매우 편리하게 트랜잭션을 적용하는 방식이다.
선언적 트랜잭션 관리는 과거에 XML에 설정하기도 했다.
이름 그대로 어딘가에 선언하기만 하면 트랜잭션이 적용되는 방식이다.
선언적 트랜잭션 관리가 프로그래밍 방식에 비해서 훨씬 간편하고 실용적이다.
- 그래서 실무에서는 대부분 선언적 트랜잭션 관리를 사용한다.

프로그래밍 방식 트랜잭션 관리 (programmatic transaction management)

트랜잭션 매니저 또는 트랜잭션 템플릿 등을 사용해서 트랜잭션 관련 코드를 직접 작성하는 방식이다.
프로그래밍 방식의 트랜잭션 관리는 스프링 컨테이너나 스프링 AOP 기술 없이 간단히 사용할 수 있다.
- 하지만 실무에서는 대부분 스프링 컨테이너와 스프링 AOP를 사용하기 때문에 거의 사용되지 않는다.
프로그래밍 방식 트랜잭션 관리는 테스트 시에 가끔 사용될 때는 있다.

스프링 부트의 자동 리소스 등록

스프링 부트가 등장하기 이전에는 데이터소스와 트랜잭션 매니저를 개발자가 직접 스프링 빈으로 등록해서 사용했다.
하지만 스프링 부트로 개발을 시작한 개발자라면 데이터소스나 트랜잭션 매니저를 직접 등록한 적이 없을 것이다.
사실 여태까지 개발한 것들을 살펴보면 DataSource를 직접 스프링 빈으로 등록했다.

@Bean
DataSource dataSource() {
    return new DriverManagerDataSource(URL, USERNAME, PASSWORD);
}
@Bean
PlatformTransactionManager transactionManager() {
    return new DataSourceTransactionManager(dataSource());
}

데이터 소스 자동 등록

스프링 부트는 데이터 소스(DataSource)를 스프링 빈에 자동으로 등록해준다.
- dataSource라는 이름으로 등록된다.
- 만약 개발자가 직접 데이터 소스를 빈으로 등록하게 된다면 스프링 부트는 데이터 소스를 자동으로 등록하지 않는다.
스프링 부트가 데이터 소스를 자동으로 등록할 때는 application.properties를 읽어서 그 정보를 통해 빈으로 등록한다.
- 스프링 부트가 기본으로 생성하는 데이터소스는 커넥션풀을 제공하는 HikariDataSource이다.
- 커넥션풀과 관련된 설정도 application.properties 를 통해서 지정할 수 있다.
- spring.datasource.url 속성이 없으면 내장 데이터베이스(메모리 DB)를 생성하려고 시도한다.

spring.datasource.url=jdbc:h2:tcp://localhost/~/test
spring.datasource.username=sa
spring.datasource.password=

트랜잭션 매니저 자동 등록

스프링 부트는 적절한 트랜잭션 매니저(PlatformTransactionManager)를 자동으로 스프링 빈에 등록한다.
- transactionManager라는 이름으로 등록된다.
- 만약 개발자가 직접 트랜잭션 매니저를 빈으로 등록하면 스프링 부트는 트랜잭션 매니저를 자동으로 등록하지 않는다.
어떤 트랜잭션 매니저를 선택할지는 현재 등록된 라이브러리를 보고 판단한다.
- JDBC를 사용하면 DataSourceTransactionManager를 빈으로 등록한다.
- JPA를 사용하면 JpaTransactionManager를 빈으로 등록한다.
- 만약에 JDBC랑 JPA 둘 다 사용하면 JpaTransactionManager를 빈으로 등록한다.
  - JpaTransactionManager는 DataSourceTransactionManager가 제공하는 기능 대부분을 지원하기 때문이다.

테스트

아까 작성한 값들을 실제로 application.properties에 작성해보자.

spring.datasource.url=jdbc:h2:tcp://localhost/~/test
spring.datasource.username=sa
spring.datasource.password=

그리고 MemberServiceV3_3Test를 복사해서 MemberServiceV3_4Test를 만들자.
그런 다음에 TestConfig를 아래와 같이 바꿔주자.

@TestConfiguration
static class TestConfig {
    private final DataSource dataSource;
    public TestConfig(DataSource dataSource) {
        this.dataSource = dataSource;
    }
    @Bean
    MemberRepositoryV3 memberRepositoryV3() {
        return new MemberRepositoryV3(dataSource);
    }
    @Bean
    MemberServiceV3_3 memberServiceV3_3() {
        return new MemberServiceV3_3(memberRepositoryV3());
    }
}

실제로 테스트를 실행해보면
스프링 부트가 application.properties에 지정된 속성을 참고해서
자동으로 데이터 소스와 트랜잭션 매니저를 생성해주는 것을 알 수 있다.

출처

스프링 DB 1편 - 데이터 접근 핵심 원리

[스프링 DB 1편] 스프링과 문제 해결 - 트랜잭션

애플리케이션 구조

가장 중요한 계층

문제점들

기존 서비스 살펴보기 (MemberServiceV1)

기존 서비스 살펴보기 (MemberServiceV2)

결국 핵심은 뭘까?

문제점 - 트랜잭션 문제

문제점 - 예외 누수

문제점 - JDBC 반복 문제

스프링과 문제 해결

트랜잭션 추상화

구현 기술에 따른 트랙잭션 사용법

트랜잭션 추상화

스프링의 트랜잭션 추상화

트랜잭션 동기화

트랜잭션 추상화

리소스 동기화

트랜잭션 동기화 매니저

트랜잭션 동기화 매니저의 동작 원리

트랜잭션 문제 해결 - 트랜잭션 매니저1

리포지토리

서비스

테스트

트랜잭션 문제 해결 - 트랜잭션 매니저2

트랜잭션 매니저의 동작 흐름

트랜잭션 문제 해결 - 트랜잭션 템플릿

반복되는 코드

TransactionTemplate

서비스

테스트

트랜잭션 문제 해결 - 트랜잭션 AOP 이해

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

트랜잭션 문제 해결 - 트랜잭션 AOP 적용

테스트

트랜잭션 문제 해결 - 트랜잭션 AOP 정리

선언적 트랜잭션 관리 (Declarative Transaction Management)

프로그래밍 방식 트랜잭션 관리 (programmatic transaction management)

스프링 부트의 자동 리소스 등록

데이터 소스 자동 등록

트랜잭션 매니저 자동 등록

테스트

출처

관련된 글

공통 예외 처리 (Advice)

커스텀 어노테이션

정적 리소스 제공