[Renewal] 트랜잭션, DB 락 이해

참고자료:

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

 

트랜잭션 개념 이해

데이터를 저장할 때 단순히 파일에 저장해도 되는데, 데이터베이스에 저장하는 이유는 무엇일까? 여러가지 이유가 있지만, 가장 대표적인 이유는 바로 데이터베이스는 트랜잭션이라는 개념을 지원하기 때문이다.

 

트랜잭션을 이름 그대로 번역하면 거래라는 뜻이다. 이것을 쉽게 풀어서 이야기하면, 데이터베이스에서 트랜잭션은 하나의 거래를 안전하게 처리하도록 보장해주는 것을 뜻한다. 그런데 하나의 거래를 안전하게 처리하려면 생각보다 고려해야 할 점이 많다. 예를 들어, A의 5000원을 B에게 계좌이체한다고 생각해보자. A의 잔고를 5000원 감소하고, B의 잔고를 5000원 증가해야 한다.

 

5000원 계좌 이체

1. A의 잔고를 5000원 감소
2. B의 잔고를 5000원 증가

계좌이체라는 거래는 이렇게 2가지 작업이 합쳐져서 하나의 작업처럼 동작해야 한다. 만약, 1번은 성공했는데 2번에서 시스템에 문제가 발생하면 계좌이체는 실패하고 A의 잔고만 5000원 감소하는 심각한 문제가 발생한다. 데이터베이스가 제공하는 트랜잭션 기능을 사용하면, 1번과 2번 둘 다 함께 성공해야 저장하고, 중간에 하나라도 실패하면 거래전의 상태로 돌아갈 수 있다. 만약, 1번은 성공했는데 2번에서 시스템에 문제가 발생하면 계좌이체는 실패하고 거래 전의 상태로 완전히 돌아갈 수 있다. 결과적으로 A의 잔고가 감소하지 않는다.

 

모든 작업이 성공해서 데이터베이스에 정상 반영하는 것을 커밋(Commit)이라 하고, 작업 중 하나라도 실패해서 거래 이전으로 되돌리는 것을 롤백(Rollback)이라 한다.

 

트랜잭션 ACID

트랜잭션은 ACID라 하는 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability)을 보장해야 한다.

• 원자성: 트랜잭션 내에서 실행한 작업들은 마치 하나의 작업인 것처럼 모두 성공하거나 모두 실패해야 한다.
• 일관성: 모든 트랜잭션은 일관성 있는 데이터베이스 상태를 유지해야 한다. 예를 들어, 데이터베이스에서 정한 무결성 제약 조건을 항상 만족해야 한다.
• 격리성: 동시에 실행되는 트랜잭션들이 서로에게 영향을 미치지 않도록 격리한다. 예를 들어, 동시에 같은 데이터를 수정하지 못하도록 해야 한다. 격리성은 동시성과 관련된 성능 이슈로 인해 트랜잭션 격리 수준(Isolation Level)을 선택할 수 있다.
• 지속성: 트랜잭션을 성공적으로 끝내고 나면 그 결과가 항상 기록되어야 한다. 중간에 시스템에 문제가 발생해도 데이터베이스 로그 등을 사용해서 성공한 트랜잭션 내용을 복구해야 한다.

트랜잭션 격리 수준(Isolation Level)

• READ UNCOMMITED - 커밋되지 않은 읽기
• READ COMMITED - 커밋된 읽기
• REPEATABLE READ - 반복 가능한 읽기
• SERIALIZABLE - 직렬화 가능

 

데이터베이스 연결 구조와 DB 세션

트랜잭션을 더 자세히 이해하기 위해 데이터베이스 서버 연결 구조와 DB 세션에 대해 알아보자.

• 사용자는 웹 애플리케이션 서버(WAS)나 DB 접근 툴 같은 클라이언트를 사용해서 데이터베이스 서버에 접근할 수 있다. 클라이언트는 데이터베이스 서버에 연결을 요청하고 커넥션을 맺게 된다. 이때 데이터베이스 서버는 내부에 세션이라는 것을 만든다. 그리고 앞으로 해당 커넥션을 통한 모든 요청은 이 세션을 통해서 실행하게 된다.
• 쉽게 이야기해서, 개발자가 클라이언트를 통해 SQL을 전달하면 현재 커넥션에 연결된 세션이 SQL을 실행한다.
• 세션은 트랜잭션을 시작하고, 커밋 또는 롤백을 통해 트랜잭션을 종료한다. 그리고 이후에 새로운 트랜잭션을 다시 시작할 수 있다.
• 사용자가 커넥션을 닫거나, 또는 DBA가 세션을 강제로 종료하면 세션은 종료된다.

• 커넥션 풀이 10개의 커넥션을 생성하면, 세션도 10개가 만들어진다. 

트랜잭션 DB 예제1 - 개념 이해

트랜잭션 동작을 예제를 통해 확인해보자. 이번 시간에는 먼저 트랜잭션의 동작 개념의 전체 그림을 이해하는데 집중하자. 

참고로, 지금부터 설명하는 내용은 트랜잭션 개념의 이해를 돕기 위해 예시로 설명하는 것이다. 구체적인 실제 구현 방식은 데이터베이스마다 다르다. 

 

트랜잭션 사용법

• 데이터 변경 쿼리를 실행하고 데이터베이스에 그 결과를 반영하려면 커밋 명령어인 `commit`을 호출하고, 결과를 반영하고 싶지 않으면 롤백 명령어인 `rollback`을 호출하면 된다.
• 커밋을 호출하기 전까지는 임시로 데이터를 저장하는 것이다. 따라서 해당 트랜잭션을 시작한 세션(사용자)에게만 변경 데이터가 보이고 다른 세션(사용자)에게는 변경 데이터가 보이지 않는다.
• 등록, 수정, 삭제 모두 같은 원리로 동작한다. 앞으로는 등록, 수정, 삭제를 간단히 변경이라는 단어로 표현하겠다.

• 세션1, 세션2 둘 다 가운데 있는 기본 테이블을 조회하면 해당 데이터가 그대로 조회된다.

 

세션1에서 신규 데이터 추가

• 세션1은 트랜잭션을 시작하고 신규 회원1, 신규 회원2를 DB에 추가했다. 아직 커밋은 하지 않은 상태이다.
• 새로운 데이터는 임시 상태로 저장된다.
• 세션1은 SELECT 쿼리를 실행해서 본인이 입력한 신규 회원1, 신규 회원2를 조회할 수 있다.
• 세션2는 SELECT 쿼리를 실행해도 신규 회원들을 조회할 수 없다. 왜냐하면 세션1이 아직 커밋을 하지 않았기 때문이다.

커밋하지 않은 데이터를 다른 곳에서 조회할 수 있으면 어떤 문제가 발생할까?

• 예를 들어, 커밋하지 않은 데이터가 보인다면, 세션2는 데이터를 조회했을 때 신규 회원1, 2가 보일 것이다. 따라서 신규 회원1, 신규 회원2가 있다고 가정하고 어떤 로직을 수행할 수 있다. 그런데 세션1이 롤백을 수행하면 신규 회원1, 신규 회원2의 데이터가 사라질 것이다. 따라서 데이터 정합성에 큰 문제가 생긴다.
• 세션2에서 세션1이 아직 커밋하지 않은 변경 데이터가 보인다면, 세션1이 롤백했을 때 심각한 문제가 발생할 수 있다. 따라서 커밋 전의 데이터는 다른 세션에서 보이면 안된다!

세션1 신규 데이터 추가 후 커밋

• 세션1이 신규 데이터를 추가한 후 커밋을 호출했다.
• 커밋으로 새로운 데이터가 실제 데이터베이스에 반영된다. 데이터의 상태도 임시에서 완료로 변경되었다.
• 이제 다른 세션에서도 회원 테이블을 조회하면 신규 회원들을 확인할 수 있다.

 

세션1 신규 데이터 추가 후 롤백

• 세션1이 신규 데이터를 추가한 후에 커밋 대신 롤백을 호출했다.
• 세션1이 데이터베이스에 반영한 모든 데이터가 트랜잭션을 시작하기 직전의 상태로 복구된다.
• 수정하거나 삭제한 데이터도 롤백을 호출하면 모두 트랜잭션을 시작하기 직전의 상태로 복구된다.

 

트랜잭션 - 자동 커밋, 수동 커밋

자동 커밋

트랜잭션을 사용하려면, 먼저 자동 커밋과 수동 커밋을 이해해야 한다. 자동 커밋으로 설정하면 각각의 쿼리 실행 직후에 자동으로 커밋을 호출한다. 따라서 커밋이나 롤백을 직접 호출하지 않아도 되는 편리함이 있다. 하지만 쿼리를 하나하나 실행할 때마다 자동으로 커밋이 되어버리기 때문에 우리가 원하는 트랜잭션 기능을 제대로 사용할 수 없다.

 

자동 커밋 설정

set autocommit true; //자동 커밋 모드 설정
insert into member(member_id, money) values ('data1',10000); //자동 커밋 
insert into member(member_id, money) values ('data2',10000); //자동 커밋

 

수동 커밋 설정

set autocommit false; //수동 커밋 모드 설정
insert into member(member_id, money) values ('data3',10000); 
insert into member(member_id, money) values ('data4',10000); 
commit; //수동 커밋

 

보통은 자동 커밋 모드가 기본으로 설정된 경우가 많기 때문에, 수동 커밋 모드로 설정하는 것을 트랜잭션을 시작한다고 표현한다. 수동 커밋 설정을 하면 이후에 꼭 commit, rollback 둘 중 하나를 호출해야 한다. 참고로 수동 커밋 모드나 자동 커밋 모드는 한번 설정하면 해당 세션에서는 계속 유지된다. 중간에 변경하는 것은 가능하다. 

 

만약, 자동 커밋 모드로 동작하는데 계좌이체 중간에 실패하면 어떻게 될까? 쿼리를 하나 실행할 때마다 바로바로 커밋이 되어버리기 때문에 특정 유저의 돈만 빠져나가는 심각한 문제가 발생한다. 이는 데이터베이스에서 가장 중요한 성질 중 하나인 원자성을 위배하는 것이다.

 

원자성: 트랜잭션 내에서 실행한 작업은 마치 하나의 작업인 것처럼 모두 성공하거나 모두 실패해야 한다. 

 

그렇기 때문에, 자동 커밋이 아닌 수동 커밋으로 설정하고 모든 작업이 성공적으로 끝나면 커밋을, 하나라도 실패하면 모두 되돌리는 롤백을 하여 트랜잭션의 원자성 기능을 최대한 사용해야 한다. 

 

DB 락 개념 이해

세션1이 트랜잭션을 시작하고 데이터를 수정하는 동안 아직 커밋을 수행하지 않았는데, 세션2에서 동시에 같은 데이터를 수정하게 되면 여러가지 문제가 발생한다. 바로 트랜잭션의 원자성이 깨지는 것이다. 여기에 더해서 세션1이 중간에 롤백을 하게 되면, 세션2는 잘못된 데이터를 수정하는 문제가 발생한다. 이런 문제를 방지하려면, 세션이 트랜잭션을 시작하고 데이터를 수정하는 동안에는 커밋이나 롤백 전까지 다른 세션에서 해당 데이터를 수정할 수 없게 막아야 한다. 

 

이런 문제를 바로 락이라는 개념이 해결한다.

• 세션1은 memberA의 금액을 500원으로 변경하고 싶고, 세션2는 같은 memberA의 금액을 1000원으로 변경하고 싶다.
• 데이터베이스는 이런 문제를 해결하기 위해 락(Lock)이라는 개념을 제공한다.
• 다음 예시를 통해 동시에 데이터를 수정하는 문제를 락으로 어떻게 해결하는지 자세히 알아보자.

• 세션1은 트랜잭션을 시작한다.
• 세션1은 memberA의 money를 500으로 변경을 시도한다. 이때, 해당 로우의 락을 먼저 획득해야 한다. 락이 남아 있으므로 세션1은 락을 획득한다. (세션1이 간발의 차이로 세션2보다 먼저 요청했다)
• 세션1은 락을 획득했으므로 해당 로우에 UPDATE 쿼리를 수행한다.

• 세션2는 트랜잭션을 시작한다.
• 세션2도 memberA의 money 데이터를 변경하려고 시도한다. 이때, 해당 로우의 락을 먼저 획득해야 한다.
• 그런데 락이 없다. 락이 돌아올 때까지 대기한다.
• 참고로 세션2가 락을 무한정 대기하는 것은 아니다. 락 대기 시간을 넘어가면 락 타임아웃 오류가 발생한다. 락 대기 시간은 설정할 수 있다. 락을 대기하다가 락 대기 시간을 넘어가면 아래와 같은 에러 메시지를 확인할 수 있다. (H2 데이터베이스 기준)

  Timeout trying to lock table {0}; SQL statement:
  update member set money=10000 - 2000 where member_id = 'memberA' [50200-200]
  HYT00/50200

• 세션1은 커밋을 수행한다. 커밋으로 트랜잭션이 종료되었으므로 락도 반납한다.

• 락을 획득하기 위해 대기하던 세션2가 락을 획득한다.

• 세션2는 UPDATE 쿼리를 수행한다.

• 세션2는 커밋을 수행하고 트랜잭션이 종료되었으므로 락을 반납한다.

 

DB 락 - 조회

일반적인 조회는 락을 사용하지 않는다.

• 데이터베이스마다 다르지만, 보통 데이터를 조회할 때는 락을 획득하지 않고 바로 데이터를 조회할 수 있다. 예를 들어서 세션1이 락을 획득하고 데이터를 변경하고 있어도, 세션2에서 데이터를 조회할 수 있다. 물론 세션2에서 조회가 아니라 데이터를 변경하려면 락이 필요하기 때문에 락이 돌아올 때까지 대기해야 한다. 

조회와 락

• 데이터를 조회할 때도 락을 획득하고 싶을 때가 있다. 이럴 때는 SELECT .. FOR UPDATE 구문을 사용하면 된다.
• 이렇게 하면 세션1이 조회 시점에 락을 가져가버리기 때문에 다른 세션에서 해당 데이터를 변경할 수 없다.
• 물론 이 경우도 트랜잭션을 커밋하면 락을 반납한다. 
• 또한, 세션1에서 SELECT ... FOR UPDATE 쿼리를 실행할 때, 락이 없으면 락이 돌아올 때까지 세션1은 대기한다.

그럼 조회 시점에 왜 필요할까?

• 트랜잭션 종료 시점까지 해당 데이터를 다른 곳에서 변경하지 못하도록 강제로 막아야 할 때 사용한다.
• 예를 들어, 애플리케이션 로직에서 memberA의 금액을 조회한 다음에 이 금액 정보로 애플리케이션에서 어떤 중요한 계산을 수행한다. 그런데 이 계산이 매우 중요한 계산이라 계산이 완료될 때까지 memberA의 금액을 다른곳에서 변경하면 안된다. 이럴때, 조회 시점에 락을 획득하면 된다.

SELECT * 
FROM member 
WHERE member_id='memberA' FOR UPDATE;

 

 

트랜잭션 - 자바 예제1

실제 애플리케이션에서 DB 트랜잭션을 사용해서 계좌이체와 같은 원자성이 중요한 비즈니스 로직을 어떻게 구현하는지 알아보자. 그런데 일단 트랜잭션 없이 단순하게 계좌이체 비즈니스 로직만 구현해보자. 즉, 오토커밋이라는 말이다.

 

MemberServiceV1

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.domain.Member;
import cwchoiit.jdbc.repository.MemberRepositoryV1;
import lombok.RequiredArgsConstructor;

import java.sql.SQLException;

@RequiredArgsConstructor
public class MemberServiceV1 {

    private final MemberRepositoryV1 memberRepository;

    public void accountTransfer(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("이체중 예외 발생");
        }
    }
}

• fromId의 회원을 조회해서 toId 회원에게 money 만큼의 돈을 계좌이체하는 로직이다.
• 예외 상황을 테스트해보기 위해 toId가 "ex"인 경우 예외를 발생시킨다.

MemberServiceV1Test

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.connection.ConnectionConst;
import cwchoiit.jdbc.domain.Member;
import cwchoiit.jdbc.repository.MemberRepositoryV1;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.jdbc.datasource.DriverManagerDataSource;

import java.sql.SQLException;

import static cwchoiit.jdbc.connection.ConnectionConst.*;
import static org.assertj.core.api.Assertions.*;
import static org.junit.jupiter.api.Assertions.*;

class MemberServiceV1Test {

    public static final String MEMBER_A = "memberA";
    public static final String MEMBER_B = "memberB";
    public static final String MEMBER_EX = "ex";

    private MemberRepositoryV1 memberRepository;
    private MemberServiceV1 memberService;

    @BeforeEach
    void beforeEach() {
        DriverManagerDataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);
        memberRepository = new MemberRepositoryV1(dataSource);
        memberService = new MemberServiceV1(memberRepository);
    }

    @AfterEach
    void afterEach() throws SQLException {
        memberRepository.delete(MEMBER_A);
        memberRepository.delete(MEMBER_B);
        memberRepository.delete(MEMBER_EX);
    }

    @Test
    @DisplayName("정상 이체")
    void accountTransfer() throws SQLException {
        Member memberA = new Member(MEMBER_A, 10000);
        Member memberB = new Member(MEMBER_B, 10000);

        memberRepository.save(memberA);
        memberRepository.save(memberB);

        memberService.accountTransfer(memberA.getMemberId(), memberB.getMemberId(), 2000);

        Member findMemberA = memberRepository.findById(memberA.getMemberId());
        Member findMemberB = memberRepository.findById(memberB.getMemberId());

        assertThat(findMemberA.getMoney()).isEqualTo(8000);
        assertThat(findMemberB.getMoney()).isEqualTo(12000);
    }

    @Test
    @DisplayName("이체 중 예외")
    void accountTransfer_ex() throws SQLException {
        Member memberA = new Member(MEMBER_A, 10000);
        Member memberEx = new Member(MEMBER_EX, 10000);

        memberRepository.save(memberA);
        memberRepository.save(memberEx);

        assertThatThrownBy(() -> memberService.accountTransfer(memberA.getMemberId(), memberEx.getMemberId(), 2000))
                .isInstanceOf(IllegalStateException.class);

        Member findMemberA = memberRepository.findById(memberA.getMemberId());
        Member findMemberEx = memberRepository.findById(memberEx.getMemberId());

        assertThat(findMemberA.getMoney()).isEqualTo(8000);
        assertThat(findMemberEx.getMoney()).isEqualTo(10000);
    }
}

• 두 개의 테스트가 있다. [정상 이체], [이체 중 예외]
• [정상 이체] 테스트의 경우, 이체 과정에서 아무런 문제가 발생하지 않기 때문에 의도대로 동작하는 것을 확인할 수 있을 것이다.
• [이체 중 예외] 테스트의 경우, toId가 `ex`이기 때문에 중간에 예외가 발생한다. 그런데 문제는 트랜잭션이 없기 때문에 (다른 말로 오토커밋 모드이기 때문에) 쿼리 하나하나가 나갈때마다 전부 커밋이 된다. 그래서 결국 fromId의 돈만 2000원이 빠져나가고, toId의 돈은 그대로인 최악의 사태가 발생한다. 
• 이게 바로 트랜잭션의 필요성이다. 지금은 원자성을 위배해버렸다.

 

트랜잭션 - 자바 예제2 - 트랜잭션 사용

이번에는 DB 트랜잭션을 사용해서 앞서 발생한 문제점을 해결해보자. 어떤 문제점이 있었나? 바로 memberA의 돈을 빼긴 했는데 memberEx의 계좌에 돈을 추가하는 과정에서 에러가 발생해서 memberA의 돈만 빠져나가고 memberEx의 계좌에는 돈이 그대로인 최악중 최악의 문제가 발생했다. 즉, 트랜잭션의 원자성을 활용하지 못하는 문제가 발생했다. 

 

그래서, 트랜잭션을 사용해서 모두가 성공하거나 모두가 실패하게 만들어보자. 그럼 고민이 하나 생긴다.

어디에 트랜잭션을 걸어야 할까? 쉽게 이야기해서 트랜잭션을 어디에서 시작하고 어디에서 끝내야 할까?

• 트랜잭션은 비즈니스 로직이 있는 서비스 계층에서 시작해야 한다. 비즈니스 로직이 잘못되면 해당 비즈니스 로직으로 인해 문제가 되는 부분을 함께 롤백해야 하기 때문이다.
• 그런데 트랜잭션을 시작하려면 커넥션이 필요하다. 결국 서비스 계층에서 커넥션을 만들고, 트랜잭션 커밋 이후에 커넥션을 종료해야 한다.
• 애플리케이션에서 DB 트랜잭션을 사용하려면, 트랜잭션을 사용하는 동안 같은 커넥션을 유지해야 한다. 그래야 같은 세션을 사용할 수 있다.

애플리케이션에서 같은 커넥션을 유지하려면 어떻게 해야 할까? 가장 단순한 방법은 커넥션을 파라미터로 전달해서 같은 커넥션이 사용되도록 유지하는 것이다. 먼저 리포지토리가 파라미터를 통해 같은 커넥션을 유지할 수 있도록 파라미터를 추가해보자.

MemberRepositoryV2

package cwchoiit.jdbc.repository;

import cwchoiit.jdbc.domain.Member;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;

import javax.sql.DataSource;
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.NoSuchElementException;

@Slf4j
@RequiredArgsConstructor
public class MemberRepositoryV2 {

    private final DataSource dataSource;

    public Member save(Member member) throws SQLException {
        String sql = "INSERT INTO member (member_id, money) VALUES (?, ?)";


        try (Connection connection = getConnection();
             PreparedStatement stmt = connection.prepareStatement(sql)) {
            stmt.setString(1, member.getMemberId());
            stmt.setInt(2, member.getMoney());
            stmt.executeUpdate();
            return member;
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        }
    }

    public Member findById(String memberId) throws SQLException {
        String sql = "SELECT * FROM member WHERE member_id = ?";

        try (Connection connection = getConnection();
             PreparedStatement stmt = connection.prepareStatement(sql)) {
            stmt.setString(1, memberId);

            try (ResultSet rs = stmt.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 with id = " + memberId);
                }
            }
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        }
    }

    public Member findById(Connection connection, String memberId) throws SQLException {
        String sql = "SELECT * FROM member WHERE member_id = ?";

        try (PreparedStatement stmt = connection.prepareStatement(sql)) {
            stmt.setString(1, memberId);

            try (ResultSet rs = stmt.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 with id = " + memberId);
                }
            }
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        }
    }

    public void update(String memberId, int money) throws SQLException {
        String sql = "UPDATE member SET money = ? WHERE member_id = ?";
        try (Connection connection = getConnection();
             PreparedStatement stmt = connection.prepareStatement(sql)) {

            stmt.setInt(1, money);
            stmt.setString(2, memberId);
            int resultSize = stmt.executeUpdate();
            log.info("resultSize = {}", resultSize);
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        }
    }

    public void update(Connection connection, String memberId, int money) throws SQLException {
        String sql = "UPDATE member SET money = ? WHERE member_id = ?";
        try (PreparedStatement stmt = connection.prepareStatement(sql)) {

            stmt.setInt(1, money);
            stmt.setString(2, memberId);
            int resultSize = stmt.executeUpdate();
            log.info("resultSize = {}", resultSize);
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        }
    }

    public void delete(String memberId) throws SQLException {
        String sql = "DELETE FROM member WHERE member_id = ?";

        try (Connection connection = getConnection();
             PreparedStatement stmt = connection.prepareStatement(sql)) {

            stmt.setString(1, memberId);
            stmt.executeUpdate();
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        }
    }

    private Connection getConnection() throws SQLException {
        Connection con = dataSource.getConnection();
        log.info("get connection = {}, class = {}", con, con.getClass());
        return con;
    }
}

• 코드를 보면, V2는 기존 코드와 같지만, 커넥션 유지가 필요한 다음 두 메서드가 추가되었다. 
• findById(Connection connection, String memberId)
• update(Connection connection, String memberId, int money)

주의할 부분이 있다!

• 커넥션 유지가 필요한 두 메서드는 파라미터로 넘어온 커넥션을 사용해야 한다. 그러므로 메서드 안에서 getConnection()을 호출해서는 절대 안된다!
• 커넥션 유지가 필요한 두 메서드는 리포지토리에서 커넥션을 닫으면 안된다. 커넥션을 전달 받은 리포지토리 뿐만 아니라 이후에도 커넥션을 계속 이어서 사용하기 때문이다. 그래서 이후 서비스 로직이 끝날 때 트랜잭션을 종료하고 커넥션을 닫아야 한다.

MemberServiceV2

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.domain.Member;
import cwchoiit.jdbc.repository.MemberRepositoryV1;
import cwchoiit.jdbc.repository.MemberRepositoryV2;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;

import javax.sql.DataSource;
import java.sql.Connection;
import java.sql.SQLException;

@Slf4j
@RequiredArgsConstructor
public class MemberServiceV2 {

    private final DataSource dataSource;
    private final MemberRepositoryV2 memberRepository;

    public void accountTransfer(String fromId, String toId, int money) throws SQLException {
        Connection connection = dataSource.getConnection();

        try {
            connection.setAutoCommit(false);

            bizLogic(connection, fromId, toId, money);

            connection.commit();
        } catch (Exception e) {
            connection.rollback();
            throw new IllegalStateException(e);
        } finally {
            releaseConnection(connection);
        }
    }

    private void bizLogic(Connection connection, String fromId, String toId, int money) throws SQLException {
        Member fromMember = memberRepository.findById(connection, fromId);
        Member toMember = memberRepository.findById(connection, toId);

        memberRepository.update(connection, fromId, fromMember.getMoney() - money);

        validation(toMember);

        memberRepository.update(connection, toId, toMember.getMoney() + money);
    }

    private void releaseConnection(Connection connection) {
        if (connection != null) {
            try {
                connection.setAutoCommit(true);
                connection.close(); // 커넥션 풀을 사용할땐 close()가 반납
            } catch (Exception e) {
                log.error("error, ", e);
            }
        }
    }

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

• 이제 서비스 로직이 있는 accountTransfer() 메서드를 유심히 보자.

public void accountTransfer(String fromId, String toId, int money) throws SQLException {
    Connection connection = dataSource.getConnection();

    try {
        connection.setAutoCommit(false);

        bizLogic(connection, fromId, toId, money);

        connection.commit();
    } catch (Exception e) {
        connection.rollback();
        throw new IllegalStateException(e);
    } finally {
        releaseConnection(connection);
    }
}

• 트랜잭션이 시작하려면 먼저 커넥션이 필요하기 때문에, 커넥션을 가져온다. 
• 그런 다음, 트랜잭션을 시작한다는 말은 다른 말로 수동 커밋을 사용한다는 의미이다. 따라서 커넥션을 수동 커밋 모드로 변경한다.
• 그런 다음 실질적인 비즈니스 로직을 수행한다. 보기 편하게 따로 메서드를 추출했다. 또한, 트랜잭션을 관리하는 로직과 비즈니스 로직을 구분하기 위해서도 메서드를 추출했다.

private void bizLogic(Connection connection, String fromId, String toId, int money) throws SQLException {
    Member fromMember = memberRepository.findById(connection, fromId);
    Member toMember = memberRepository.findById(connection, toId);

    memberRepository.update(connection, fromId, fromMember.getMoney() - money);

    validation(toMember);

    memberRepository.update(connection, toId, toMember.getMoney() + money);
}

• 비즈니스 로직을 잘 보면, 리포지토리에 커넥션을 파라미터로 넘겨서 사용하는 것을 볼 수 있다.

public void accountTransfer(String fromId, String toId, int money) throws SQLException {
    Connection connection = dataSource.getConnection();

    try {
        connection.setAutoCommit(false);

        bizLogic(connection, fromId, toId, money);

        connection.commit();
    } catch (Exception e) {
        connection.rollback();
        throw new IllegalStateException(e);
    } finally {
        releaseConnection(connection);
    }
}

• 비즈니스 로직이 정상적으로 끝나면 당연히 커밋을 호출해야 한다.
• 그런데 만약, 비즈니스 로직을 수행하던 중 오류가 발생하면 이 트랜잭션에서 수행했던 모든 작업을 트랜잭션을 수행하기 전 모습으로 돌려야 한다. 따라서, catch 블록에서 롤백을 수행하고 있다.
• 모든 작업이 끝나면 항상 커넥션을 반납해야 한다. 따라서 finally 블록에서 커넥션을 정리하는 메서드를 호출한다.

private void releaseConnection(Connection connection) {
    if (connection != null) {
        try {
            connection.setAutoCommit(true);
            connection.close(); // 커넥션 풀을 사용할땐 close()가 반납
        } catch (Exception e) {
            log.error("error, ", e);
        }
    }
}

• 커넥션을 정리를 할때, 반드시 반납하기 전 오토 커밋 모드를 다시 `true`로 변경해야 한다. 왜냐하면 기본이 자동 커밋이기 때문에 누군가는 자동 커밋을 예상하고 로직을 작성할 수 있다. DriverManager를 통해 필요할때마다 커넥션을 생성하고 바로 닫아버리면 상관이 없다. 그런데 커넥션 풀을 사용하는 경우 수동 커밋으로 변경하고 다시 자동 커밋으로 돌려 놓은 후에 커넥션을 반납하지 않으면 이 커넥션은 계속 수동 커밋 모드인 상태로 남아 있게 된다. 그러면 누군가는 자동 커밋을 생각하고 커밋을 호출안하면 이건 굉장히 큰 문제를 야기한다.

이제 기존에 사용했던 테스트 코드를 다시 실행해보자!

MemberServiceV2Test

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.domain.Member;
import cwchoiit.jdbc.repository.MemberRepositoryV2;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.jdbc.datasource.DriverManagerDataSource;

import java.sql.SQLException;

import static cwchoiit.jdbc.connection.ConnectionConst.*;
import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.assertThatThrownBy;

class MemberServiceV2Test {

    public static final String MEMBER_A = "memberA";
    public static final String MEMBER_B = "memberB";
    public static final String MEMBER_EX = "ex";

    private MemberRepositoryV2 memberRepository;
    private MemberServiceV2 memberService;

    @BeforeEach
    void beforeEach() {
        DriverManagerDataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);
        memberRepository = new MemberRepositoryV2(dataSource);
        memberService = new MemberServiceV2(dataSource, memberRepository);
    }

    @AfterEach
    void afterEach() throws SQLException {
        memberRepository.delete(MEMBER_A);
        memberRepository.delete(MEMBER_B);
        memberRepository.delete(MEMBER_EX);
    }

    @Test
    @DisplayName("정상 이체")
    void accountTransfer() throws SQLException {
        Member memberA = new Member(MEMBER_A, 10000);
        Member memberB = new Member(MEMBER_B, 10000);

        memberRepository.save(memberA);
        memberRepository.save(memberB);

        memberService.accountTransfer(memberA.getMemberId(), memberB.getMemberId(), 2000);

        Member findMemberA = memberRepository.findById(memberA.getMemberId());
        Member findMemberB = memberRepository.findById(memberB.getMemberId());

        assertThat(findMemberA.getMoney()).isEqualTo(8000);
        assertThat(findMemberB.getMoney()).isEqualTo(12000);
    }

    @Test
    @DisplayName("이체 중 예외")
    void accountTransfer_ex() throws SQLException {
        Member memberA = new Member(MEMBER_A, 10000);
        Member memberEx = new Member(MEMBER_EX, 10000);

        memberRepository.save(memberA);
        memberRepository.save(memberEx);

        assertThatThrownBy(() -> memberService.accountTransfer(memberA.getMemberId(), memberEx.getMemberId(), 2000))
                .isInstanceOf(IllegalStateException.class);

        Member findMemberA = memberRepository.findById(memberA.getMemberId());
        Member findMemberEx = memberRepository.findById(memberEx.getMemberId());

        assertThat(findMemberA.getMoney()).isEqualTo(10000);
        assertThat(findMemberEx.getMoney()).isEqualTo(10000);
    }
}

• 두 개의 테스트가 있다. [정상 이체], [이체 중 예외]
• [정상 이체] 테스트는 기존과 동일하게 잘 동작한다.
• [이체 중 예외] 테스트는 이제 같은 트랜잭션을 사용하고 문제가 발생하면 롤백이 일어나기 때문에, memberA의 2000원을 차감하는데는 성공했어도 memberEx에게 2000원을 추가하는 부분에서 문제가 발생하기 때문에 이 트랜잭션에서 일어난 모든 작업이 다시 롤백된다. 따라서, 최종적으로 두 회원 모두 원래대로 10000원으로 돌아간다.

 

이렇게 트랜잭션을 사용해서, 원자성을 유지할 수 있게 됐다. 이게 바로 트랜잭션의 힘이다.

 

문제

그런데 문제가 있다. V1, V2서비스 코드를 비교해서 다시 한번 보자.

V1

public void accountTransfer(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);
}

V2

public void accountTransfer(String fromId, String toId, int money) throws SQLException {
    Connection connection = dataSource.getConnection();

    try {
        connection.setAutoCommit(false);

        bizLogic(connection, fromId, toId, money);

        connection.commit();
    } catch (Exception e) {
        connection.rollback();
        throw new IllegalStateException(e);
    } finally {
        releaseConnection(connection);
    }
}

• 트랜잭션을 사용한 코드를 보면, 어찌된게 서비스 로직보다 트랜잭션을 처리하는 코드가 더 많다. 이는 서비스 계층의 역할을 과하게 늘리게 되고, 비즈니스 로직에 다른 코드가 추가되니 코드 자체도 지저분해진다. 
• 추가적으로 트랜잭션을 사용하는 코드마다 파라미터에 커넥션을 넘겨야 하니 그 또한 골치거리다.
• 이런 문제를 스프링은 기가막히게 해결해주는데, 그 기가막힌 해결법을 다음 포스팅에서 알아보자!