programmer.cwchoiit

참고자료

저번 포스팅에 이어서 진행하자. 저번 포스팅까지 트랜잭션에 대해 알아보았다. 트랜잭션을 사용하니 원자성을 유지할 수 있었으나 여러 문제점들이 있었는데 어떤 문제가 있었는지를 차근차근 알아보면서 그 문제점들을 스프링이 어떻게 완벽하게 해결해주는지 알아보자.

문제점들

애플리케이션 구조

여러가지 애플리케이션 구조가 있지만, 가장 단순하면서 많이 사용하는 방법은 역할에 따라 3가지 계층으로 나누는 것이다.

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

순수한 서비스 계층

여기서 가장 중요한 곳은 바로 핵심 비즈니스 로직이 있는 서비스 계층이다. 시간이 흘러서 UI(웹)와 관련된 부분이 변하고, 데이터 저장 기술을 다른 기술로 변경해도, 비즈니스 로직은 최대한 변경없이 유지되어야 한다. 이렇게 하려면 서비스 계층을 특정 기술에 종속적이지 않게 개발해야 한다. 위처럼 계층을 나눈 이유도 서비스 계층을 최대한 순수하게 유지하기 위한 목적이 크다. 기술에 종속적인 부분은 프레젠테이션 계층, 데이터 접근 계층에서 가지고 간다. 

• 프레젠테이션 계층은 클라이언트가 접근하는 UI와 관련된 기술인 웹, 서블릿, HTTP와 관련된 부분을 담당해준다. 그래서 서비스 계층을 이런 UI와 관련된 기술로부터 보호해준다. 예를 들어서, HTTP API를 사용하다가 GRPC와 같은 기술로 변경해도 프레젠테이션 계층의 코드만 변경하고, 서비스 계층은 변경하지 않아도 된다.
• 데이터 접근 계층은 데이터를 저장하고 관리하는 기술을 담당해준다. 그래서 JDBC, JPA와 같은 구체적인 데이터 접근 기술로부터 서비스 계층을 보호해준다. 예를 들어서 JDBC를 사용하다가 JPA로 변경해도 서비스 계층은 변경하지 않아도 된다. 물론 서비스 계층에서 데이터 접근 계층을 직접 접근하는 것이 아니라, 인터페이스를 제공하고 서비스 계층은 이 인터페이스에 의존하는 것이 좋다. 그래야 서비스 코드의 변경없이 JdbcRepository를 JpaRepository로 변경할 수 있다.

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

그럼 서비스 계층을 순수하게 유지하는게 좋다는 것은 알았다. 지금까지 개발한 MemberService 코드들을 살펴보자.

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

• V1은 특정 기술에 거의 종속적이지 않고 순수한 비즈니스 로직만 존재한다.
• 특정 기술과 관련된 코드가 거의 없어서 코드가 깔끔하고, 유지보수 하기 쉽다. 보면, MemberRepository에만 의존하고 있는데 이것 역시 특정 기술에 의존하는게 아니라 인터페이스에 의존하고 이 인터페이스를 구현한 구현체를 얼마든 갈아끼워도 상관이 없게 설계하면 된다.
• 향후 비즈니스 로직의 변경이 필요하면 이 부분을 변경하면 된다.
• 물론, 남은 문제가 있다 여기서도. 바로 SQLException을 의존하고 있다는 것. 이건 MemberRepository에서 올라오는 예외인데 원래라면 이 예외는 저 Repository에서 처리하는 게 맞다. 이것도 이후에 알아보자. 지금은 이 코드는 그저 예시를 위한 코드일뿐이다.

다음은 트랜잭션을 적용한 V2 코드를 살펴보자.

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

• 트랜잭션은 비즈니스 로직이 있는 서비스 계층에서 시작하는 것이 좋다.
• 그런데 문제는 트랜잭션을 사용하기 위해서 javax.sql.DataSource, java.sql.Connection, java.sql.SQLException 같은 JDBC 기술에 의존해야 한다는 점이다.
• 트랜잭션을 사용하기 위해 JDBC 기술에 의존하고 있는 서비스 계층이다. 결과적으로 비즈니스 로직보다 JDBC를 사용해서 트랜잭션을 처리하는 코드가 더 많다.
• 향후 JDBC에서 JPA로 기술을 변경하면 서비스 코드도 모두 함께 변경해야 한다.
• 핵심 비즈니스 로직과 JDBC 기술이 섞여 있어서 유지보수가 어렵다.

문제를 정리해보면

• 트랜잭션 문제
• 예외 누수 문제
• JDBC 반복 문제

이렇게 크게 세가지가 있다. 

트랜잭션 문제

가장 큰 문제는 트랜잭션을 적용하면서 생긴 다음과 같은 문제들이다.

• JDBC 구현 기술이 서비스 계층에 누수되는 문제
  • 트랜잭션을 적용하기 위해 JDBC 구현 기술이 서비스 계층에 누수되었다.
  • 서비스 계층은 순수해야 한다. 구현 기술을 변경해도 서비스 계층 코드는 최대한 유지할 수 있어야 한다.
  • 서비스 계층은 특정 기술에 종속되지 않아야 한다. 지금까지 그렇게 열심히 노력해서 데이터 접근 계층으로 JDBC 관련 코드를 모았다(Repository 클래스에서 UPDATE, INSERT, DELETE, SELECT를 하는 등). 그런데 트랜잭션을 적용하면서 결국 서비스 계층에 JDBC 구현 기술의 누수가 발생했다.
• 트랜잭션 동기화 문제
  • 같은 트랜잭션을 유지하기 위해 커넥션을 파라미터로 넘겨야 한다.
  • 이때 파생되는 문제도 있다. 똑같은 기능도 트랜잭션용 기능과 트랜잭션을 유지하지 않아도 되는 기능으로 분리해야 한다.
• 트랜잭션 적용 반복 문제
  • 트랜잭션 적용 코드를 보면 반복이 많다. `try - catch - finally`...

예외 누수

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

JDBC 반복 문제

• 지금까지 작성한 MemberRepository 코드는 순수한 JDBC 코드를 사용했다.
• 근데 이 코드들은 유사한 코드의 반복이 너무 많다.
  • `try - catch - finally`
  • 커넥션을 열고, PreparedStatement를 사용하고, 결과를 매핑하고, 실행하고, 리소스를 정리하고.

이런 여러 문제가 있는데, 스프링은 지금 말한 모든 문제를 모두 아름답게 해결해준다. 이제 이 문제를 스프링을 사용해서 하나씩 해결해보자!

트랜잭션 추상화

현재 서비스 계층은 트랜잭션을 사용하기 위해서 JDBC 기술에 의존하고 있다. 향후 JDBC에서 JPA와 같은 다른 데이터 접근 기술로 변경하면, 서비스 계층의 트랜잭션 관련 코드도 모두 함께 수정해야 한다.

무슨 말이냐면, 구현 기술에 따라 트랜잭션 사용방법이 다 다르다.

• JDBC: `con.setAutoCommit(false)`
• JPA: `transaction.begin()`

JDBC 트랜잭션 의존

JDBC 기술 → JPA 기술로 변경

이렇게 JDBC 기술을 사용하다가 JPA로 기술을 변경하게 되면, 서비스 계층의 코드도 JPA 기술을 사용하도록 함께 수정해야 한다.

이런 문제를 해결하려면 트랜잭션 기능을 추상화하면 된다. 아주 단순하게 생각하면 다음과 같은 인터페이스를 만들어서 사용하면 된다.

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

• 트랜잭션은 사실 단순하다. 트랜잭션을 시작하고, 비즈니스 로직이 수행되고, 끝나면 커밋또는 롤백을 하면 된다.
• 그리고 이 트랜잭션 매니저 인터페이스를 기반으로 아래와 같이 각각의 기술에 맞는 구현체를 만들면 된다.
  • JdbcTxManager: JDBC 트랜잭션 기능을 제공하는 구현체
  • JpaTxManager: JPA 트랜잭션 기능을 제공하는 구현체

• 서비스는 특정 트랜잭션 기술에 직접 의존하는 것이 아니라, TxManager라는 추상화된 인터페이스에 의존한다.
• 이제 원하는 구현체를 DI를 통해서 주입하면 된다. 예를 들어서 JDBC 트랜잭션 기능이 필요하면 JdbcTxManager를 서비스에 주입하고, JPA 트랜잭션 기능으로 변경해야 하면 JpaTxManager를 주입하면 된다. 
• 클라이언트 서비스는 인터페이스에 의존하고 DI를 사용한 덕분에 OCP 원칙을 지키게 되었다. 이제 트랜잭션을 사용하는 서비스 코드를 전혀 변경하지 않고, 트랜잭션 기술을 마음껏 변경할 수 있다.

스프링의 트랜잭션 추상화

스프링은 이미 이런 고민을 다 해두었다. 우리는 스프링이 제공하는 트랜잭션 추상화 기술을 사용하면 된다. 심지어 데이터 접근 기술에 따른 트랜잭션 구현체도 대부분 만들어두어서 가져다가 사용만 하면 된다.

• 스프링의 트랜잭션 추상화의 핵심은 PlatformTransactionManager 인터페이스이다.
• org.springframework.transaction.PlatformTransactionManager

package org.springframework.transaction;

import org.springframework.lang.Nullable;

public interface PlatformTransactionManager extends TransactionManager {

	TransactionStatus getTransaction(@Nullable TransactionDefinition definition) throws TransactionException;

	void commit(TransactionStatus status) throws TransactionException;

	void rollback(TransactionStatus status) throws TransactionException;

}

• getTransaction(): 트랜잭션을 시작한다. 이름이 getTransaction인 이유는 기존에 이미 진행중인 트랜잭션이 있는 경우 해당 트랜잭션에 참여할 수 있기 때문이다. 참고로 트랜잭션 참여, 전파에 대한 부분은 뒤에서 설명한다. 지금은 단순히 트랜잭션을 시작하는 것으로 이해하면 된다.
• commit(): 트랜잭션을 커밋한다.
• rollback(): 트랜잭션을 롤백한다.

앞으로, PlatformTransactionManager 인터페이스와 구현체를 포함해서 트랜잭션 매니저로 줄여서 이야기 하겠다.

트랜잭션 동기화

스프링이 제공하는 트랜잭션 매니저는 크게 2가지 역할을 한다.

• 트랜잭션 추상화
• 리소스 동기화

트랜잭션 추상화

바로 위에서 이야기 했다. PlatformTransactionManager를 사용해서 트랜잭션 기술을 추상화한다는 이야기.

리소스 동기화

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

커넥션과 세션

• 이 그림을 보면 알 수 있듯, 하나의 커넥션이 하나의 세션을 가지고 있고 이 세션안에서 작업을 해야 하나의 작업으로 간주된다. 즉, 트랜잭션의 시작부터 끝까지 같은 데이터베이스 커넥션을 유지해야 하나의 작업에서 롤백과 커밋이 제대로 작동한다는 의미이다. 

트랜잭션 매니저와 트랜잭션 동기화 매니저

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

동작 방식

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

쓰레드 로컬을 사용하면 각각의 쓰레드마다 별도의 저장소가 부여된다. 따라서 해당 쓰레드만 해당 데이터에 접근할 수 있다.

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

이제 본격적으로 애플리케이션 코드에 트랜잭션 매니저를 적용해보자.

MemberRepositoryV3

package cwchoiit.jdbc.repository;

import cwchoiit.jdbc.domain.Member;
import lombok.RequiredArgsConstructor;
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
@RequiredArgsConstructor
public class MemberRepositoryV3 {

    private final DataSource dataSource;

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

        Connection connection = null;
        PreparedStatement stmt = null;

        try {
            connection = getConnection();
            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;
        } finally {
            close(connection, stmt, null);
        }
    }

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

        Connection connection = null;
        PreparedStatement stmt = null;
        ResultSet rs = null;

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

            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;
        } finally {
            close(connection, stmt, rs);
        }
    }

    public void update(String memberId, int money) throws SQLException {
        String sql = "UPDATE member SET money = ? WHERE member_id = ?";

        Connection connection = null;
        PreparedStatement stmt = null;

        try {
            connection = getConnection();
            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;
        } finally {
            close(connection, stmt, null);
        }
    }

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

        Connection connection = null;
        PreparedStatement stmt = null;
        try {

            connection = getConnection();
            stmt = connection.prepareStatement(sql);

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

    private void close(Connection connection, Statement stmt, ResultSet rs) {
        JdbcUtils.closeResultSet(rs);
        JdbcUtils.closeStatement(stmt);
        // 주의! 트랜잭션 동기화를 제대로 사용하려면 DataSourceUtils 를 사용해야 한다.
        DataSourceUtils.releaseConnection(connection, dataSource);
    }

    private Connection getConnection() throws SQLException {
        // 주의! 트랜잭션 동기화를 제대로 수행하려면, DataSourceUtils 를 사용해야 한다.
        Connection connection = DataSourceUtils.getConnection(dataSource);
        log.info("get connection = {}, class = {}", connection, connection.getClass());
        return connection;
    }
}

• 우선 동일한 커넥션을 사용하기 위해 파라미터로 전달해야 했던 메서드는 모두 제거했다.
• getConnection() → 이제 커넥션을 획득할때 DataSourceUtils를 사용해서 커넥션을 가져온다. 이 녀석은 트랜잭션 동기화 매니저가 관리하는 커넥션이 있으면 해당 커넥션을 반환하고, 없으면 새로운 커넥션을 생성해서 반환한다. 우리는 트랜잭션 매니저를 사용해야 하니까 당연히 이렇게 가져와야 한다.
• close() → close()라는 메서드에서 자원을 정리하는데 커넥션의 경우, DataSourceUtils를 사용해서 releaseConnection()을 호출하고 있다. 이 부분을 주의해야 하는데, 만약 `connection.close()`로 커넥션을 직접 닫아버리면 커넥션이 유지가 되지 않는 문제가 발생한다. 커넥션은 이후 로직은 물론이고 트랜잭션이 종료될때까지 살아있어야 한다. 그러니까 커넥션을 레포지토리에서 닫으면 안된다는 얘기다. 그럼 releaseConnection()은 무엇을 할까?
  • 트랜잭션을 사용하기 위해 동기화된 커넥션은 커넥션을 닫지 않고 그대로 유지해준다. 
  • 트랜잭션 동기화 매니저가 관리하는 커넥션이 없는 경우 해당 커넥션을 닫는다.
• 트랜잭션을 종료(롤백, 커밋)하는 시점은 트랜잭션을 시작하는 부분인 서비스 레이어에서 일어나야 한다! 

MemberServiceV3_1

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.domain.Member;
import cwchoiit.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 transaction = transactionManager.getTransaction(new DefaultTransactionDefinition());

        try {
            bizLogic(fromId, toId, money);
            transactionManager.commit(transaction);
        } catch (Exception e) {
            transactionManager.rollback(transaction);
            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("이체중 예외 발생");
        }
    }
}

• PlatformTransactionManager를 주입받는 서비스 클래스가 생겼다. 이제 트랜잭션을 사용하는 기술이 JDBC이든, JPA이든 상관없이 구현체를 갈아끼워 주입만 시켜주면 이 서비스 코드는 수정할 필요가 전혀없이 기술을 변경할 수 있다.
• transactionManager.getTransaction()으로 트랜잭션을 시작했다. 반환값은 TransactionStatus 타입을 반환하는데 현재 트랜잭션의 상태 정보가 포함되어 있다. 이 반환값은 이후 롤백 또는 커밋을 할 때 필요하다.
• new DefaultTransactionDefinition() 이 녀석은 트랜잭션과 관련된 옵션을 지정할 수 있는데 자세한 내용은 뒤에서 설명한다.
• transactionManager.commit(transaction) → 트랜잭션 내 모든 로직이 정상적으로 수행되면 커밋을 호출한다.
• transactionManager.rollback(transaction) → 트랜잭션 내 로직 중 하나라도 실패하면 롤백을 호출한다.

MemberServiceV3_1Test

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.domain.Member;
import cwchoiit.jdbc.repository.MemberRepositoryV2;
import cwchoiit.jdbc.repository.MemberRepositoryV3;
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.DataSourceTransactionManager;
import org.springframework.jdbc.datasource.DriverManagerDataSource;
import org.springframework.transaction.PlatformTransactionManager;

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 MemberServiceV3_1Test {

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

    private MemberRepositoryV3 memberRepository;
    private MemberServiceV3_1 memberService;

    @BeforeEach
    void beforeEach() {
        DriverManagerDataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);
        memberRepository = new MemberRepositoryV3(dataSource);

        PlatformTransactionManager transactionManager = new DataSourceTransactionManager(dataSource);
        memberService = new MemberServiceV3_1(transactionManager, 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);
    }
}

• 이제 테스트 코드를 통해 제대로 수행되는지 확인하자. 가장 중요한 부분은 초기화 코드이다.

@BeforeEach
void beforeEach() {
    DriverManagerDataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);
    memberRepository = new MemberRepositoryV3(dataSource);

    PlatformTransactionManager transactionManager = new DataSourceTransactionManager(dataSource);
    memberService = new MemberServiceV3_1(transactionManager, memberRepository);
}

• 우리는 지금 JDBC 기술을 사용중이므로, JDBC용 트랜잭션 매니저인 DataSourceTransactionManager를 구현체로 사용해야 한다. 그리고 이 구현체를 MemberServiceV3_1에 주입한다. 
• 트랜잭션 매니저는 내부에서 데이터소스를 통해 커넥션을 획득하므로 DataSource가 필요하다.
• 테스트를 실행하면 정상적으로 수행되는 것을 확인할 수 있다.

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

그림으로 트랜잭션 매니저의 전체 동작 흐름을 자세히 이해해보자.

트랜잭션 매니저 - 트랜잭션 시작

• 클라이언트의 요청으로 서비스 로직을 실행한다.
• 서비스 계층에서 transactionManager.getTransaction()을 호출해서 트랜잭션을 시작한다.
• 트랜잭션을 시작하려면 먼저 데이터베이스 커넥션이 필요하다. 트랜잭션 매니저는 내부에서 데이터소스를 사용해서 커넥션을 생성한다.
• 커넥션을 수동 커밋 모드로 변경해서 실제 데이터베이스 트랜잭션을 시작한다.
• 커넥션을 트랜잭션 동기화 매니저에 보관한다.
• 트랜잭션 동기화 매니저는 쓰레드 로컬에 커넥션을 보관한다. 따라서, 멀티쓰레드 환경에 안전하게 커넥션을 보관할 수 있다.

트랜잭션 매니저 - 로직 실행

• 서비스는 비즈니스 로직을 실행하면서 레포지토리의 메서드들을 호출한다. 이때, 이제는 커넥션을 파라미터로 전달하지 않는다.
• 레포지토리 메서드들은 트랜잭션이 시작된 커넥션이 필요하다. 레포지토리는 DataSourceUtils.getConnection()을 사용해서 트랜잭션 동기화 매니저에 보관된 커넥션을 꺼내서 사용한다. 이 과정을 통해서 자연스럽게 같은 커넥션을 사용하고, 트랜잭션도 유지된다.
• 획득한 커넥션을 사용해서 SQL을 데이터베이스에 전달해서 실행한다.

트랜잭션 매니저 - 트랜잭션 종료

• 비즈니스 로직이 끝나고 트랜잭션을 종료한다. 트랜잭션은 커밋하거나 롤백하면 종료된다.
• 트랜잭션을 종료하려면 동기화된 커넥션이 필요하다. 트랜잭션 동기화 매니저를 통해 동기화된 커넥션을 획득한다.
• 획득한 커넥션을 통해 데이터베이스에 트랜잭션을 커밋하거나 롤백한다.
• 전체 리소스를 정리한다.
  • 트랜잭션 동기화 매니저를 정리한다. 쓰레드 로컬은 사용 후 꼭 정리해야 한다.
  • conn.setAutoCommit(true)로 되돌린다. 커넥션 풀을 고려해야 한다.
  • conn.close()를 호출해서 커넥션을 종료한다. 커넥션 풀을 사용하는 경우, conn.close()를 호출하면 커넥션 풀에 반환된다.

정리를 하자면

• 트랜잭션 추상화 덕분에 서비스 코드는 이제 JDBC 기술에 의존하지 않고, PlatformTransactionManager에 의존한다. 따라서, 향후 JDBC에서 JPA로 기술을 변경해도 DataSourceTransactionManager에서 JpaTransactionManager로 구현체만 갈아끼워주면 서비스 코드에는 아무런 변경도 할 필요가 없다.
• 트랜잭션 동기화 매니저 덕분에 커넥션을 파라미터로 넘기지 않아도 된다.

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

아직 남은 문제가 있다. 위 코드를 살펴보면 다음과 같은 패턴이 반복된다.

public void accountTransfer(String fromId, String toId, int money) throws SQLException {

    TransactionStatus transaction = transactionManager.getTransaction(new DefaultTransactionDefinition());

    try {
        bizLogic(fromId, toId, money);
        transactionManager.commit(transaction);
    } catch (Exception e) {
        transactionManager.rollback(transaction);
        throw new IllegalStateException(e);
    }
}

• 트랜잭션을 시작한다. 
• 성공하면 커밋한다.
• 실패하면 롤백한다.
• try - catch 구문
• 모든 서비스에서 이 형태의 코드가 반복될 것이다. 

이럴때 템플릿 콜백 패턴을 활용하면 이런 문제를 해결할 수가 있다.

트랜잭션 템플릿

템플릿 콜백 패턴을 적용하려면 템플릿을 제공하는 클래스를 작성해야 한다. 그런데 스프링은 또 우리를 위해 TransactionTemplate이라는 템플릿 클래스를 제공한다.

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

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

MemberServiceV3_2

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.domain.Member;
import cwchoiit.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 org.springframework.transaction.support.TransactionTemplate;

import java.sql.SQLException;

@Slf4j
public class MemberServiceV3_2 {

    private final TransactionTemplate transactionTemplate;
    private final MemberRepositoryV3 memberRepository;

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

    public void accountTransfer(String fromId, String toId, int money) throws SQLException {
        transactionTemplate.executeWithoutResult(status -> {
            try {
                bizLogic(fromId, toId, money);
            } catch (SQLException e) {
                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("이체중 예외 발생");
        }
    }
}

• TransactionTemplate을 사용하려면 TransactionManager가 필요하다. 생성자에서 TransactionManager를 주입 받으면서 TransactionTemplate을 생성했다.
• 트랜잭션 템플릿 사용한 코드를 보자.

public void accountTransfer(String fromId, String toId, int money) throws SQLException {
    transactionTemplate.executeWithoutResult(status -> {
        try {
            bizLogic(fromId, toId, money);
        } catch (SQLException e) {
            throw new IllegalStateException(e);
        }
    });
}

• 굉장히 깔끔하게 딱 비즈니스 로직만 작성해도 되게끔 변경됐다.
• 트랜잭션을 시작하거나, 커밋, 롤백하는 부분도 다 없어졌다.
• 트랜잭션 템플릿의 기본 동작은 비즈니스 로직이 정상 수행되면 커밋하고, 언체크 예외가 발생하면 롤백한다. 그 외의 경우(체크 예외가 발생하는 경우나 정상적으로 끝나는 경우)에는 커밋한다. 기본 흐름이 그렇다. 이 또한 변경할수도 있다.
• 그런데 살짝 아쉬운 부분은 bizLogic 자체가 SQLException을 던지기 때문에 그것을 잡아줘야 하는 try - catch 구문이 들어간다. 만약 로직을 언체크 예외로 작성했다면 이 부분도 없어질 것이다. 이건 뒤에서 차차 알아보자.

정리를 하자면

• 트랜잭션 템플릿을 사용하니 반복하는 코드를 최대한 제거할 수 있었다.
• 하지만, 여전히 서비스 로직에 비즈니스 로직뿐만 아니라 트랜잭션을 처리하는 기술인 트랜잭션 템플릿 코드가 함께 포함되어 있다.
• 즉, 두 관심사가 동시에 로직에 쓰여지고 있다는 말인데 이걸 어떻게 깔끔하게 서비스 코드에는 비즈니스 로직만 남겨두게 할 수 있을까?

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

• 지금까지 트랜잭션을 편리하게 처리하기 위해 트랜잭션 추상화도 도입하고, 추가로 반복적인 트랜잭션 로직을 해결하기 위해 트랜잭션 템플릿도 도입했다.
• 트랜잭션 템플릿 덕분에 트랜잭션을 처리하는 반복적인 코드는 해결할 수 있었다. 하지만, 서비스 계층에 순수한 비즈니스 로직만 남긴다는 목표는 아직 달성하지 못했다.
• 이럴때, 스프링 AOP를 통해 프록시를 도입하면 문제를 깔끔하게 해결할 수 있다.

프록시를 통한 문제 해결

프록시 도입 전

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

프록시 도입 후

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

이 내용의 깊은 부분은 스프링 AOP에 대해 완전히 이해해야 한다. 그 부분에 대한 내용 역시 포스팅으로 정리해 두었다. 

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

MemberServiceV3_3

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.domain.Member;
import cwchoiit.jdbc.repository.MemberRepositoryV3;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.transaction.PlatformTransactionManager;
import org.springframework.transaction.annotation.Transactional;
import org.springframework.transaction.support.TransactionTemplate;

import java.sql.SQLException;

@Slf4j
@RequiredArgsConstructor
public class MemberServiceV3_3 {

    private final MemberRepositoryV3 memberRepository;

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

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

• 순수한 비즈니스 로직만 남기고, 트랜잭션 관련 코드는 모두 제거됐다.
• 스프링이 제공하는 트랜잭션 AOP를 적용하기 위해 @Transactional 애노테이션을 추가했다.
• @Transactional 애노테이션은 메서드에 붙여도 되고, 클래스에 붙여도 된다. 클래스에 붙이면 외부에서 호출 가능한 public 메서드가 AOP 적용 대상이 된다.

MemberServiceV3_3Test

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.domain.Member;
import cwchoiit.jdbc.repository.MemberRepositoryV3;
import lombok.extern.slf4j.Slf4j;
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.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.context.TestConfiguration;
import org.springframework.context.annotation.Bean;
import org.springframework.jdbc.datasource.DataSourceTransactionManager;
import org.springframework.jdbc.datasource.DriverManagerDataSource;
import org.springframework.transaction.PlatformTransactionManager;

import javax.sql.DataSource;
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;

@Slf4j
@SpringBootTest
class MemberServiceV3_3Test {

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

    @Autowired
    private MemberRepositoryV3 memberRepository;

    @Autowired
    private MemberServiceV3_3 memberService;

    @TestConfiguration
    static class TestContextConfiguration {
        @Bean
        DataSource dataSource() {
            return new DriverManagerDataSource(URL, USERNAME, PASSWORD);
        }

        @Bean
        PlatformTransactionManager transactionManager() {
            return new DataSourceTransactionManager(dataSource());
        }

        @Bean
        MemberRepositoryV3 memberRepository() {
            return new MemberRepositoryV3(dataSource());
        }

        @Bean
        MemberServiceV3_3 memberService() {
            return new MemberServiceV3_3(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);
    }
}

• 스프링 AOP를 적용한 테스트를 하기 위해서는 @SpringBootTest 애노테이션을 붙여줘야 테스트를 실행할 때 스프링이 띄워진다. 그리고 @Autowired 애노테이션으로 필요한 빈들을 주입받을 수 있다.
• @TestConfiguration 애노테이션은 테스트 안에서 내부 설정 클래스를 만들어서 사용하면서 이 애노테이션을 붙이면, 스프링 부트가 자동으로 만들어주는 빈들에 추가적으로 필요한 스프링 빈들을 등록하고 테스트를 수행할 수 있다.
• 테스트를 실행해보면, 정상적으로 수행되는 것을 확인할 수 있다.

참고자료:

트랜잭션 개념 이해

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

트랜잭션을 이름 그대로 번역하면 거래라는 뜻이다. 이것을 쉽게 풀어서 이야기하면, 데이터베이스에서 트랜잭션은 하나의 거래를 안전하게 처리하도록 보장해주는 것을 뜻한다. 그런데 하나의 거래를 안전하게 처리하려면 생각보다 고려해야 할 점이 많다. 예를 들어, 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);
    }
}

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

참고자료

커넥션 풀 이해

• 이전 포스팅에서 해봤지만, 애플리케이션과 데이터베이스를 연동하기 위해선 데이터베이스의 커넥션을 얻어와야 한다. 그런데 이 커넥션을 얻어오는 과정은 복잡하다. 
  • 애플리케이션 로직은 DB 드라이버를 통해 커넥션을 조회한다.
  • DB 드라이버는 DB와 TCP/IP 커넥션을 연결한다. 물론 이 과정에서 3 way handshake 같은 TCP/IP 연결을 위한 네트워크 동작도 발생한다.
  • DB 드라이버는 TCP/IP 커넥션이 연결되면, ID, PW와 기타 부가정보를 DB에 전달한다.
  • DB는 ID, PW를 통해 내부 인증을 완료하고, 내부에 DB 세션을 생성한다.
  • DB는 커넥션 생성이 완료되었다는 응답을 보낸다.
  • DB 드라이버는 커넥션 객체를 생성해서 클라이언트에 반환한다.

이렇게 커넥션을 새로 만드는 것은 과정도 복잡하고 시간도 많이 소요되는 일이다. DB는 물론이고 애플리케이션 서버에서도 TCP/IP 커넥션을 새로 생성하기 위한 리소스를 매번 사용해야 한다. 진짜 문제는 고객이 애플리케이션을 사용할 때, SQL을 실행하는 시간 뿐만 아니라 커넥션을 새로 만드는 시간이 추가되기 때문에 결과적으로 응답 속도에 영향을 준다. 이것은 사용자에게 좋지 않은 경험을 줄 수 있다. 

이런 문제를 한번에 해결하는 아이디어가 바로 커넥션을 미리 생성해두고, 사용하는 커넥션 풀이라는 방법이다.

커넥션 풀은 이름 그대로 커넥션을 관리하는 풀이다.

애플리케이션을 시작하는 시점에 커넥션 풀은 필요한만큼 커넥션을 미리 확보해서 풀에 보관한다. 보통 얼마나 보관할지는 서비스의 특징과 서버 스펙에 따라 다르지만 기본값은 보통 10개이다. 

커넥션 풀에 들어 있는 커넥션은 TCP/IP로 DB와 커넥션이 연결되어 있는 상태이기 때문에 언제든지 즉시 SQL을 DB에 전달할 수 있다.

애플리케이션 로직에서 이제는 DB 드라이버를 통해서 새로운 커넥션을 획득하는 것이 아니다. 이제는 커넥션 풀을 통해 이미 생성되어 있는 커넥션을 객체 참조로 그냥 가져다 사용하면 된다. 커넥션 풀에 커넥션을 요청하면 커넥션 풀은 자신이 가지고 있는 커넥션 중에 하나를 반환한다. 

애플리케이션 로직은 커넥션 풀에서 받은 커넥션을 사용해서 SQL을 데이터베이스에 전달하고, 그 결과를 받아서 처리한다. 커넥션을 모두 사용하고 나면 이제는 커넥션을 종료하는 것이 아니라, 다음에 다시 사용할 수 있도록 해당 커넥션을 그대로 커넥션 풀에 반납하면 된다. 여기서 주의할 점은 커넥션을 종료하는 것이 아니라 커넥션이 살아있는 상태로 커넥션 풀에 반환해야 한다는 것이다.

정리를 하자면

• 적절한 커넥션 풀 숫자는 서비스의 특징과 애플리케이션 서버 스펙, DB 서버 스펙에 따라 다르기 때문에 성능 테스트를 통해서 정해야 한다.
• 커넥션 풀은 서버당 최대 커넥션 수를 제한할 수 있다. 따라서 DB에 무한정 연결이 생성되는 것을 막아주어서 DB를 보호하는 효과도 있다. 
• 이런 커넥션 풀은 얻는 이점이 매우 크기 때문에 실무에서는 항상 기본으로 사용한다.
• 커넥션 풀은 개념적으로 단순해서 직접 구현할 수도 있지만 사용도 편리하고 성능도 뛰어난 오픈소스 커넥션 풀이 많기 때문에 오픈소스를 사용하자.
• 대표적인 오픈소스는 HikariCP 이것만 알면 된다. 스프링 부트 2.0부터는 기본 커넥션 풀로 hikariCP를 제공한다.

DataSource 이해

그럼 이제, 커넥션 풀까지 이해했으면 커넥션을 얻는 방법은 앞서 학습한 JDBC DriverManager를 직접 사용하거나, 커넥션 풀을 사용하는 등 다양한 방법이 존재한다는 것을 알게됐다.

• 이렇게 커넥션을 획득하는 방법이 다양하다. 
• 그런데, 만약 DriverManager를 통해 커넥션을 획득하다가 커넥션 풀로 변경하고 싶어서 변경하면 어떻게 될까?

예를 들어, 애플리케이션 로직에서 DriverManager를 사용해서 커넥션을 획득하다가 HikariCP 같은 커넥션 풀을 사용하도록 변경하면 커넥션을 획득하는 애플리케이션 코드도 함께 변경해야 한다. 의존관계가 DriverManager에서 HikariCP로 변경되기 때문이다. 물론 둘의 사용법도 다를 것이다. 

이런 경우 자바는 항상 뭐다? 표준과 구현체를 제공한다.

그렇다. 자바에서는 이런 문제를 해결하기 위해 커넥션을 획득하는 방법을 추상화 하는데 그게 바로 DataSource이다.

• 자바에서는 커넥션을 획득하는 방법을 추상화하는 javax.sql.DataSource라는 인터페이스를 제공한다.
• 이 인터페이스의 핵심 기능은 커넥션 조회 하나이다. (다른것은 중요하지 않다)

DataSource

public interface DataSource {
    Connection getConnection() throws SQLException;
}

그러니까 정리를 하자면,

• 대부분의 커넥션 풀은 DataSource 인터페이스를 이미 구현해두었다. 따라서 개발자는 commons-dbcp2, tomcat-jdbc pool, hikariCP 등 커넥션 풀 기능을 제공하는 이 코드에 직접 의존하는게 아니라, DataSource 인터페이스에만 의존하도록 애플리케이션 로직을 작성하면 된다.
• 예를 들어, DBCP2에서 HikariCP로 커넥션 풀 구현 기술을 변경하고 싶으면 그냥 이 라이브러리만 내려받으면 끝난다.
• 하지만, 안타깝게도 DriverManager는 DataSource 인터페이스를 구현하지 않았다. 따라서 DriverManager는 이전 포스팅에서 JDBC를 직접 다룰때처럼 직접 사용해야 한다. 따라서 DriverManager를 사용하다가, DataSource 기반의 커넥션 풀을 사용하도록 변경하면 관련 코드를 다 고쳐야 한다. 이런 문제를 해결하기 위해 스프링에서는 DriverManager도 DataSource를 통해서 사용할 수 있도록 DriverManagerDataSource라는 DataSource를 구현한 클래스를 제공한다. 
• 그래서 스프링을 사용하면, DataSource라는 인터페이스에만 의존하면 커넥션 풀을 사용하는 기술이던, 직접 커넥션을 가져오던 상관없이 DataSource 인터페이스에만 의존하면 된다. 구현체만 갈아끼우면 된다는 뜻이다. 그래서 DriverManagerDataSource를 통해서 DriverManager를 사용하다가 커넥션 풀을 사용하도록 구현체를 갈아끼워도 애플리케이션 로직은 변경하지 않아도 된다.

DataSource 예제1 - DriverManagerDataSource

예제를 통해 DataSource를 한번 사용해보자.

먼저, 기존에 개발했던 DriverManager를 통해서 커넥션을 획득하는 방법을 확인해보자.

ConnectionTest

package cwchoiit.jdbc.connection;

import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.jdbc.datasource.DriverManagerDataSource;

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

import static cwchoiit.jdbc.connection.ConnectionConst.*;

@Slf4j
public class ConnectionTest {

    @Test
    void driverManager() throws SQLException {
        Connection con1 = DriverManager.getConnection(URL, USERNAME, PASSWORD);
        Connection con2 = DriverManager.getConnection(URL, USERNAME, PASSWORD);

        log.info("connection = {}, class = {}", con1, con1.getClass());
        log.info("connection = {}, class = {}", con2, con2.getClass());
    }
}

실행 결과

16:33:00.976 [Test worker] INFO cwchoiit.jdbc.connection.ConnectionTest -- connection = conn0: url=jdbc:h2:tcp://localhost/~/h2/db/jdbc user=SA, class = class org.h2.jdbc.JdbcConnection
16:33:00.978 [Test worker] INFO cwchoiit.jdbc.connection.ConnectionTest -- connection = conn1: url=jdbc:h2:tcp://localhost/~/h2/db/jdbc user=SA, class = class org.h2.jdbc.JdbcConnection

• 두번의 getConnection()을 호출해서 서로 다른 커넥션을 얻어왔음을 알 수 있다. 이게 이전 포스팅에서 해봤던 JDBC의 DriverManager를 사용해 커넥션을 가져오는 방법이다.

이번에는 스프링이 제공하는 DataSource를 구현한 DriverManagerDataSource를 사용해보자. 차이가 있다면 이 녀석을 사용하면 클라이언트 코드는 DataSource 인터페이스에만 의존하면 된다는 점이다. 직접 커넥션을 가져오든, 커넥션 풀을 통해 가져오든 말이다.

ConnectionTest

package cwchoiit.jdbc.connection;

import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.jdbc.datasource.DriverManagerDataSource;

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

import static cwchoiit.jdbc.connection.ConnectionConst.*;

@Slf4j
public class ConnectionTest {

    @Test
    void dataSourceDriverManager() throws SQLException {
        DataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);
        useDataSource(dataSource);
    }

    private void useDataSource(DataSource dataSource) throws SQLException {
        Connection con1 = dataSource.getConnection();
        Connection con2 = dataSource.getConnection();
        log.info("connection = {}, class = {}", con1, con1.getClass());
        log.info("connection = {}, class = {}", con2, con2.getClass());
    }
}

• 기존 코드와 비슷하지만 DriverManagerDataSource는 DataSource를 통해서 커넥션을 획득할 수 있다. 보면 알겠지만 타입도 DataSource로 받을 수 있다. 스프링이 제공하는 DriverManagerDataSource는 DataSource를 구현한다.

실행 결과

16:33:00.976 [Test worker] INFO cwchoiit.jdbc.connection.ConnectionTest -- connection = conn0: url=jdbc:h2:tcp://localhost/~/h2/db/jdbc user=SA, class = class org.h2.jdbc.JdbcConnection
16:33:00.978 [Test worker] INFO cwchoiit.jdbc.connection.ConnectionTest -- connection = conn1: url=jdbc:h2:tcp://localhost/~/h2/db/jdbc user=SA, class = class org.h2.jdbc.JdbcConnection

• 당연히 커넥션 풀이 아니라, 내부적으로 DriverManager를 사용하므로 두 커넥션은 서로 다른 커넥션이다. 
• 그런데, 여기서 엄청 큰 차이가 하나 있다. 바로 새로운 커넥션을 획득하더라도 파라미터를 그때그때 넘기지 않아도 된다는 점이다.

DriverManager 직접 사용 시

DriverManager.getConnection(URL, USERNAME, PASSWORD)
DriverManager.getConnection(URL, USERNAME, PASSWORD)

DataSource 사용 시

@Test
void dataSourceDriverManager() throws SQLException {
    DataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);
    useDataSource(dataSource);
}

private void useDataSource(DataSource dataSource) throws SQLException {
    Connection con1 = dataSource.getConnection();
    Connection con2 = dataSource.getConnection();
    log.info("connection = {}, class = {}", con1, con1.getClass());
    log.info("connection = {}, class = {}", con2, con2.getClass());
}

• DriverManager는 커넥션을 획득할 때마다 파라미터로 URL, USERNAME, PASSWORD를 넘겨야 한다. 반면, DataSource를 구현한 DriverManagerDataSource는 처음 객체를 생성할때 생성자로 그 값들을 넘겨주면 그 이후에 커넥션을 획득할 땐, 단순히 getConnection()만 호출하면 된다. 

이는 설정과 사용의 분리를 의미한다.

• 설정: DataSource를 만들고 필요한 속성들을 사용해서 URL, USERNAME, PASSWORD 같은 부분을 입력하는 것을 말한다. 이렇게 설정과 관련된 속성들은 한 곳에 있는 것이 향후 변경에 더 유연하게 대처할 수 있다.
• 사용: 설정은 신경쓰지 않고, DataSource의 getConnection()만 호출해서 사용하면 된다.

이런 설정과 사용의 분리가 작아보이지만 굉장히 큰 차이를 만든다. 보통 설정은 한군데에서 하더라도 사용은 여러군데에서 하는 경우가 많다. 그런데 그때 사용하는 지점에도 설정 관련 정보를 알아야 한다면 굉장히 골치아파진다. 그리고 변경할때는 더 문제다. 적용한 부분을 모두 다 수정해줘야하니 말이다.

DataSource 예제2 - 커넥션 풀

이번에는 DataSource를 통해 커넥션 풀을 사용하는 예제를 알아보자.

@Test
void dataSourceConnectionPool() throws SQLException, InterruptedException {
    HikariDataSource dataSource = new HikariDataSource();
    dataSource.setJdbcUrl(URL);
    dataSource.setUsername(USERNAME);
    dataSource.setPassword(PASSWORD);

    dataSource.setMaximumPoolSize(10);
    dataSource.setPoolName("MyPool");

    useDataSource(dataSource);
    
    Thread.sleep(1000);
}

private void useDataSource(DataSource dataSource) throws SQLException {
    Connection con1 = dataSource.getConnection();
    Connection con2 = dataSource.getConnection();
    log.info("connection = {}, class = {}", con1, con1.getClass());
    log.info("connection = {}, class = {}", con2, con2.getClass());
}

• HikariCP 커넥션 풀을 사용한다. HikariDataSource는 DataSource 인터페이스를 구현하고 있다.
• 커넥션 풀 최대 사이즈를 10으로 지정하고, 풀의 이름을 MyPool 이라고 지정했다.
• 커넥션 풀에서 커넥션을 생성하는 작업은 애플리케이션 실행 속도에 영향을 주지 않기 위해 별도의 쓰레드에서 작동한다. 별도의 쓰레드에서 동작하기 때문에 테스트가 먼저 종료되어 버린다. 예제처럼 Thread.sleep을 주면 커넥션 풀에 커넥션이 생성되는 로그를 확인할 수 있을 것이다.

실행 결과

#커넥션 풀 초기화 정보 출력
HikariConfig - MyPool - configuration:
HikariConfig - maximumPoolSize................................10 
HikariConfig - poolName................................"MyPool"
#커넥션 풀 전용 쓰레드가 커넥션 풀에 커넥션을 10개 채움
[MyPool connection adder] MyPool - Added connection conn0: url=jdbc:h2:.. user=SA
[MyPool connection adder] MyPool - Added connection conn1: url=jdbc:h2:.. user=SA
[MyPool connection adder] MyPool - Added connection conn2: url=jdbc:h2:.. user=SA
[MyPool connection adder] MyPool - Added connection conn3: url=jdbc:h2:.. user=SA
[MyPool connection adder] MyPool - Added connection conn4: url=jdbc:h2:.. user=SA
  ...
[MyPool connection adder] MyPool - Added connection conn9: url=jdbc:h2:.. user=SA

#커넥션 풀에서 커넥션 획득1
ConnectionTest - connection=HikariProxyConnection@446445803 wrapping conn0: url=jdbc:h2:tcp://localhost/~/test user=SA, class=class com.zaxxer.hikari.pool.HikariProxyConnection

#커넥션 풀에서 커넥션 획득2
ConnectionTest - connection=HikariProxyConnection@832292933 wrapping conn1: url=jdbc:h2:tcp://localhost/~/test user=SA, class=class com.zaxxer.hikari.pool.HikariProxyConnection

MyPool - After adding stats (total=10, active=2, idle=8, waiting=0)

실행 결과를 분석해보자.

HikariConfig

• HikariCP 관련 설정을 확인할 수 있다. 풀의 이름을 MyPool과 최대 풀 수 10을 확인할 수 있다.

MyPool connection adder

• 별도의 쓰레드를 사용해서 커넥션 풀에 커넥션을 채우고 있는 것을 확인할 수 있다. 이 쓰레드는 커넥션 풀에 커넥션을 최대 풀 수 10개까지 채운다.
• 그렇다면 왜 별도의 쓰레드를 사용해서 커넥션 풀에 커넥션을 채울까? 커넥션 풀에 커넥션을 채우는것은 상대적으로 오래 걸리는 일이다. 애플리케이션을 실행할 때 커넥션 풀을 채울때까지 마냥 대기하고 있다면, 애플리케이션 실행 시간이 늦어진다. 따라서, 별도의 쓰레드를 사용해서 커넥션 풀을 채워야 애플리케이션 실행 시간에 영향을 주지 않는다.

커넥션 풀에서 커넥션 획득

• 커넥션 풀에서 커넥션을 획득하고 그 결과를 출력했다. 여기서는 커넥션 풀에서 커넥션을 2개 획득하고 반환하지는 않았다. 따라서 풀에 있는 10개의 커넥션 중에 2개를 가지고 있는 상태이다. 그래서 마지막 로그를 보면 사용중인 커넥션 active=2, 풀에서 대기 상태인 커넥션 idle=8을 확인할 수 있다.

DataSource 적용

이번에는 애플리케이션에 DataSource를 적용해보자.

MemberRepositoryV1

package cwchoiit.jdbc.repository;

import cwchoiit.jdbc.connection.DBConnectionUtil;
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;

/**
 * JDBC - DataSource 사용
 */
@Slf4j
@RequiredArgsConstructor
public class MemberRepositoryV1 {

    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 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 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;
    }
}

• 기존에 사용했던 MemberRepositoryV0을 V1으로 변경했다.
• 그리고 DataSource 의존관계를 외부에서 주입받게 만들었다. 이제 직접 만든 DBConnectionUtil을 사용하지 않아도 된다. DataSource는 표준 인터페이스이기 때문에 DriverManagerDataSource에서 HikariDataSource로 변경되어도 애플리케이션 로직을 변경할 필요가 없다.

MemberRepositoryV1Test

package cwchoiit.jdbc.repository;

import com.zaxxer.hikari.HikariDataSource;
import cwchoiit.jdbc.connection.ConnectionConst;
import cwchoiit.jdbc.domain.Member;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.jdbc.datasource.DriverManagerDataSource;

import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.NoSuchElementException;

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

@Slf4j
class MemberRepositoryV1Test {

    MemberRepositoryV1 repository;

    @BeforeEach
    void beforeEach() {
        // DriverManagerDataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);

        HikariDataSource dataSource = new HikariDataSource();
        dataSource.setJdbcUrl(URL);
        dataSource.setUsername(USERNAME);
        dataSource.setPassword(PASSWORD);

        repository = new MemberRepositoryV1(dataSource);
    }

    @Test
    void crud() throws SQLException {
        Member member = new Member("member4", 10000);
        repository.save(member);

        Member findMember = repository.findById(member.getMemberId());
        log.info("findMember = {}", findMember);

        assertThat(findMember).isEqualTo(member);

        repository.update(member.getMemberId(), 20000);
        Member updatedMember = repository.findById(member.getMemberId());
        assertThat(updatedMember.getMoney()).isEqualTo(20000);

        repository.delete(member.getMemberId());
        assertThatThrownBy(() -> repository.findById(member.getMemberId()))
                .isInstanceOf(NoSuchElementException.class);
    }
}

• MemberRepositoryV1은 DataSource 의존관계 주입이 필요하다. 따라서, 모든 테스트를 수행하기 전에 실행하는 @BeforeEach 애노테이션을 사용해서, HikariDataSource로도 주입해보고, DriverManagerDataSource로도 주입해보자. 어떤걸 주입해도 아무런 문제없이 잘 동작하는 것을 볼 수 있다. 이게 바로 외부에서 의존관계를 주입하는 DI고, 의존관계 결정을 나중으로 미루는 아주 유연한 방식이다.

실행 결과

DriverManagerDataSource 사용

  get connection=conn0: url=jdbc:h2:.. user=SA class=class
  org.h2.jdbc.JdbcConnection
  get connection=conn1: url=jdbc:h2:.. user=SA class=class
  org.h2.jdbc.JdbcConnection
  get connection=conn2: url=jdbc:h2:.. user=SA class=class
  org.h2.jdbc.JdbcConnection
  get connection=conn3: url=jdbc:h2:.. user=SA class=class
  org.h2.jdbc.JdbcConnection
  get connection=conn4: url=jdbc:h2:.. user=SA class=class
  org.h2.jdbc.JdbcConnection
  get connection=conn5: url=jdbc:h2:.. user=SA class=class
  org.h2.jdbc.JdbcConnection

• DriverManagerDataSource를 사용하면, 매번 커넥션을 새로 만들어서 반환해주는 것을 확인할 수 있다. (conn0, conn1, ... conn5)

HikariDataSource 사용 (커넥션 풀)

  get connection=HikariProxyConnection@xxxxxxxx1 wrapping conn0: url=jdbc:h2:...
  user=SA
  get connection=HikariProxyConnection@xxxxxxxx2 wrapping conn0: url=jdbc:h2:...
  user=SA
  get connection=HikariProxyConnection@xxxxxxxx3 wrapping conn0: url=jdbc:h2:...
  user=SA
  get connection=HikariProxyConnection@xxxxxxxx4 wrapping conn0: url=jdbc:h2:...
  user=SA
  get connection=HikariProxyConnection@xxxxxxxx5 wrapping conn0: url=jdbc:h2:...
  user=SA
  get connection=HikariProxyConnection@xxxxxxxx6 wrapping conn0: url=jdbc:h2:...
  user=SA

• 커넥션 풀을 사용하니, conn0만 계속해서 재사용중임을 알 수 있다.
• 테스트는 순서대로 실행되기 때문에 커넥션을 사용하고 다시 돌려주는 것을 반복하고 있다. 따라서 conn0만 사용된다.

정리

이렇게 DataSource가 무엇인지, 커넥션 풀이 무엇인지 명확히 이해해봤다. 커넥션을 얻는 방법은 매우 여러가지지만, 그것을 고민할 필요없이 JDBC 표준으로 정의한 DataSource만을 의존하면 구현체가 변경되어도 어떠한 코드의 변경도 필요없이 커넥션을 가져오는 기술을 바꿀 수 있다. 이것이 바로 표준과 구현체를 만들어 사용하는 강력한 이유이다.

참고자료

JDBC 이해

애플리케이션을 개발할 때, 중요한 데이터는 대부분 데이터베이스에 보관한다.

클라이언트가 애플리케이션 서버를 통해 데이터를 저장하거나 조회하면, 애플리케이션 서버는 다음 과정을 통해서 데이터베이스를 사용한다.

• 커넥션 연결: 주로 TCP/IP를 통해 커넥션을 연결한다.
• SQL 전달: 애플리케이션 서버는 DB가 이해할 수 있는 SQL을 연결된 커넥션을 통해 DB에 전달한다.
• 결과 응답: DB는 전달된 SQL을 수행하고 그 결과를 응답한다. 애플리케이션 서버는 응답 결과를 활용한다.

문제는, 각각의 데이터베이스마다 커넥션을 연결하는 방법, SQL을 전달하는 방법, 그리고 결과를 응답 받는 방법이 모두 다르다는 점이다. 참고로 관계형 데이터베이스는 수십개가 있다. 여기에는 2가지 큰 문제가 있는데, 다음과 같다.

• 데이터베이스를 다른 종류의 데이터베이스로 변경하면 애플리케이션 서버에 개발된 데이터베이스 사용 코드도 함께 변경해야 한다.
• 개발자가 각각의 데이터베이스마다 커넥션 연결, SQL 전달, 그리고 그 결과를 응답 받는 방법을 새로 학습해야 한다.

이런 문제를 해결하기 위해 JDBC라는 자바 표준이 등장한다.

JDBC 표준 인터페이스

JDBC(Java Database Connectivity)는 자바에서 데이터베이스에 접속할 수 있도록 하는 자바 API다. JDBC는 데이터베이스에서 자료를 쿼리하거나 업데이트하는 방법을 제공한다.

대표적으로 다음 3가지 기능을 표준 인터페이스로 정의해서 제공한다.

• java.sql.Connection → 연결
• java.sql.Statement → SQL을 담은 내용
• java.sql.ResultSet → SQL 요청 응답

자바는 이렇게 표준 인터페이스를 정의해두었다. 이제부터 개발자는 이 표준 인터페이스만 사용해서 개발하면 된다. 그런데 인터페이스만 있다고해서 기능이 동작하지는 않는다. 이 JDBC 인터페이스를 각각의 DB 벤더(회사)에서 자신의 DB에 맞도록 구현해서 라이브러리로 제공하는데, 이것을 JDBC 드라이버라고 한다. 예를 들어, MySQL에 접근할 수 있는 것은 MySQL JDBC 드라이버라고 하고, OracleDB에 접근할 수 있는 것은 Oracle JDBC 드라이버라고 한다.

MySQL 드라이버 사용

Oracle 드라이버 사용

JDBC의 등장으로 다음 2가지 문제가 해결되었다.

• 데이터베이스를 다른 종류의 데이터베이스로 변경하면 애플리케이션 서버의 데이터베이스 사용 코드도 함께 변경해야 하는 문제를 애플리케이션 로직은 이제 JDBC 표준 인터페이스만 의존한다. 따라서 데이터베이스를 다른 종류의 데이터베이스로 변경하고 싶으면 JDBC 구현 라이브러리만 변경하면 된다. 즉, 드라이버만 변경하면 된다. 따라서 다른 종류의 데이터베이스로 변경해도 애플리케이션 서버의 사용 코드를 그대로 유지할 수 있다.
• 개발자가 각각의 데이터베이스마다 커넥션 연결, SQL 전달, 그리고 그 결과를 응답 받는 방법을 새로 학습해야 하는 문제를 JDBC 표준 인터페이스 사용법만 학습하면 된다. 한번 배워두면 수십개의 데이터베이스에 모두 동일하게 적용할 수 있다.

표준화의 한계도 있다. JDBC의 등장으로 많은 것이 편리해졌지만, 각각의 데이터베이스마다 SQL, 데이터타입 등의 일부 사용법이 다르다. 대표적으로 실무에서 기본으로 사용하는 페이징 SQL은 각각의 데이터베이스마다 사용법이 다르다. 결국 데이터베이스를 변경하면 JDBC 코드는 변경하지 않아도 되지만, SQL은 해당 데이터베이스에 맞도록 변경해야 한다. 

JDBC와 최신 데이터 접근 기술

JDBC는 1997년에 출시될 정도로 오래된 기술이고, 사용하는 방법도 복잡하다. 그래서 최근에는 JDBC를 직접 사용하기 보다는 JDBC를 편리하게 사용하는 다양한 기술들이 존재한다. 대표적으로 SQL Mapper와 ORM 기술로 나눌 수 있다.

• SQL Mapper
  • JDBC를 편리하게 사용하도록 도와준다.
  • SQL 응답 결과를 객체로 편리하게 변환해준다.
  • JDBC의 반복 코드를 제거해준다.
  • 개발자가 직접 SQL을 작성해야 한다.
  • 대표 기술로는 스프링 JdbcTemplate, MyBatis가 있다.

• ORM 기술
  • ORM은 객체를 관계형 데이터베이스 테이블과 매핑해주는 기술이다. 이 기술 덕분에 개발자는 반복적인 SQL을 직접 작성하지 않고, ORM 기술이 개발자 대신에 SQL을 동적으로 만들어 실행해준다. 추가로 각각의 데이터베이스마다 다른 SQL을 사용하는 문제도 중간에서 해결해준다. 
  • 대표 기술로는 JPA가 있다. 

SQL Mapper vs ORM 기술

둘 다 장단점이 있다. SQL Mapper는 SQL만 직접 작성하면 나머지 번거로운 일은 SQL Mapper가 대신 해결해준다. 그래서 SQL만 작성할 줄 알면 금방 배워서 사용할 수 있다. ORM 기술은 SQL 자체를 작성하지 않아도 되어서 개발 생산성이 매우 높아진다. 편리한 반면 쉬운 기술은 아니므로 실무에서 사용하려면 깊이있게 학습해야 한다. 

중요한 점은, 이런 기술들도 내부에서는 모두 JDBC를 사용한다. 따라서 JDBC를 직접 사용하지 않더라도, JDBC가 어떻게 동작하는지 기본원리를 알아야 한다. 그래야 해당 기술들을 더 깊이있게 이해할 수 있고, 무엇보다 문제가 발생했을 때 근본적인 문제를 찾아서 해결할 수 있다. JDBC는 자바 개발자라면 꼭 알아두어야 하는 필수 기본 기술이다.

데이터베이스 연결

애플리케이션과 데이터베이스를 연결해보자. 먼저, 데이터베이스는 H2 데이터베이스를 사용하기로 한다. 그러려면 H2 데이터베이스 라이브러리가 추가되어야 한다. 그리고 스프링 부트를 사용하여 테스트한다.

ConnectionConst

package cwchoiit.jdbc.connection;

public abstract class ConnectionConst {
    public static final String URL = "jdbc:h2:tcp://localhost/~/h2/db/jdbc";
    public static final String USERNAME = "sa";
    public static final String PASSWORD = "";
}

• 데이터베이스에 접속하는데 필요한 기본 정보를 편리하게 사용할 수 있도록 상수로 만들었다.
• 이제 JDBC를 사용해서 실제 데이터베이스에 연결하는 코드를 작성해보자.

package cwchoiit.jdbc.connection;

import lombok.extern.slf4j.Slf4j;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

import static cwchoiit.jdbc.connection.ConnectionConst.*;

@Slf4j
public class DBConnectionUtil {

    public static Connection getConnection() {
        try {
            Connection connection = DriverManager.getConnection(URL, USERNAME, PASSWORD);
            log.info("get connection = {}, class = {}", connection, connection.getClass());
            return connection;
        } catch (SQLException e) {
            throw new RuntimeException(e);
        }
    }
}

• 데이터베이스에 연결하려면, JDBC가 제공하는 DriverManager.getConnection(...)을 사용하면 된다. 이렇게 하면 라이브러리에 있는 데이터베이스 드라이버를 찾아서 해당 드라이버가 제공하는 커넥션을 반환해준다. 여기서는 H2 데이터베이스 드라이버가 작동해서 실제 데이터베이스와 커넥션을 맺고, 그 결과를 반환해 줄 것이다.

DBConnectionUtilTests

package cwchoiit.jdbc.connection;

import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;

import java.sql.Connection;

import static org.assertj.core.api.Assertions.assertThat;

@Slf4j
class DBConnectionUtilTests {

    @Test
    void connection() {
        Connection connection = DBConnectionUtil.getConnection();
        assertThat(connection).isNotNull();
    }
}

실행 결과

16:52:45.721 [Test worker] INFO cwchoiit.jdbc.connection.DBConnectionUtil -- get connection = conn0: url=jdbc:h2:tcp://localhost/~/h2/db/jdbc user=SA, class = class org.h2.jdbc.JdbcConnection

• 실행 결과를 보면 class=class org.h2.jdbc.JdbcConnection 부분을 확인할 수 있다. 이것이 바로 H2 데이터베이스 드라이버가 제공하는 H2 전용 커넥션이다. 물론 이 커넥션은 JDBC 표준 커넥션 인터페이스인 java.sql.Connection 인터페이스를 구현하고 있다.

JDBC DriverManager 연결 이해

지금까지 코드로 확인해 본 과정을 좀 더 자세히 들여다보자.

JDBC 커넥션 인터페이스와 구현

• JDBC는 java.sql.Connection 표준 커넥션 인터페이스를 정의한다.
• H2 데이터베이스 드라이버는 JDBC Connection 인터페이스를 구현한 org.h2.jdbc.JdbcConnection 구현체를 제공한다.

DriverManager 커넥션 요청 흐름

• JDBC가 제공하는 DriverManager는 라이브러리에 등록된 DB 드라이버들을 관리하고, 커넥션을 획득하는 기능을 제공한다.
• 애플리케이션 로직에서 커넥션이 필요하면 DriverManager.getConnection(...)을 호출한다.
• DriverManager는 라이브러리에 등록된 드라이버 목록을 자동으로 인식한다. 이 드라이버들에게 순서대로 다음 정보를 넘겨서 커넥션을 획득할 수 있는지 확인한다.
  • URL: jdbc:h2:tcp://localhost/~/h2/db/jdbc
  • 이름, 비밀번호 등 접속에 필요한 추가 정보
  • 여기서 각각의 드라이버는 URL 정보를 체크해서 본인이 처리할 수 있는 요청인지 확인한다. 예를 들어서 URL이 jdbc:h2로 시작하면 이것은 H2 데이터베이스에 접근하기 위한 규칙이다. 따라서 H2 드라이버는 본인이 처리할 수 있으므로 실제 데이터베이스에 연결해서 커넥션을 획득하고, 이 커넥션을 클라이언트에 반환한다. 반면에, URL이 jdbc:h2로 시작했는데 MySQL 드라이버가 먼저 실행되면 이 경우 본인이 처리할 수 없다는 결과를 반환하게 되고 다음 드라이버에게 순서가 넘어간다.
• 이렇게 찾은 커넥션 구현체가 클라이언트에 반환된다.

우리는 H2 데이터베이스 드라이버만 라이브러리에 등록했기 때문에, H2 드라이버가 제공하는 H2 커넥션을 제공받는다. 물론, 이 H2 커넥션은 JDBC가 제공하는 java.sql.Connection 인터페이스를 구현하고 있다.

참고: H2 데이터베이스 드라이버 라이브러리

runtimeOnly 'com.h2database:h2' //h2-x.x.xxx.jar

JDBC 개발 - 등록

이제 본격적으로 JDBC를 사용해서 애플리케이션을 개발해보자. 사실 JDBC를 직접 사용해서 개발할 일은 앞으로 없을테지만, 이것을 한번 해보는 것은 엄청 큰 의의가 있다. 결국 나중에 사용할 JPA도 JDBC를 사용하는 거고 다 이 JDBC를 내부적으로 사용하는 것이기 때문에.

우선, 테이블을 먼저 간단하게 만들어두자.

create table member (
  member_id varchar(10),
  money integer not null default 0,
  primary key (member_id)
);

테이블을 만들었으면 이제 시작하면 된다. 먼저 Member 클래스 하나를 만들자.

Member

package cwchoiit.jdbc.domain;

import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@NoArgsConstructor
@AllArgsConstructor
public class Member {
    private String memberId;
    private int money;
}

• 회원의 ID와 해당 회원이 소지한 금액을 표현하는 단순한 클래스이다. 앞서 만들어둔 member 테이블에 데이터를 저장하고 조회할 때 사용한다. 

가장 먼저 JDBC를 사용해서 이렇게 만든 회원 객체를 데이터베이스에 저장해보자.

MemberRepositoryV0

package cwchoiit.jdbc.repository;

import cwchoiit.jdbc.connection.DBConnectionUtil;
import cwchoiit.jdbc.domain.Member;
import lombok.extern.slf4j.Slf4j;

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.SQLException;

/**
 * JDBC - DriverManager 사용
 */
@Slf4j
public class MemberRepositoryV0 {

    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;
        }
    }

    private Connection getConnection() {
        return DBConnectionUtil.getConnection();
    }
}

• 커넥션을 획득하는 메서드인 getConnection()을 먼저 보자. 이전에 만든 DBConnectionUtil의 getConnection() 메서드를 호출하는 메서드이다. 이 MemberRepositoryV0에서 여러번 사용될 예정이라 따로 메서드로 뽑았다. 내부적으로 DriverManager를 사용한다.
• save() 메서드를 살펴보자. JDBC를 사용하려면 SQL을 직접 작성해야 한다. 여기서는 데이터를 등록해야 하므로 INSERT 쿼리를 작성한다. 
• 데이터베이스에 대한 Connection과 데이터베이스에 전달할 SQL과 파라미터로 전달할 데이터를 가지고 있는 Statement는 반드시 사용한 후 반납해야 한다. 그래서 try-with-resources 구문을 사용해서 어떤일이 있어도 반납할 수 있도록 했다.
• 회원 데이터를 만들기 위해 필요한 데이터인 `member_id`와 `money`를 파라미터로 던진다. 그때, PreparedStatement의 setString(), setInt()를 사용해서 각 숫자에 맞는(물음표가 먼저 나오는 순서대로) 파라미터를 전달한다. 
• PreparedStatement는 Statement의 자식 타입인데, `?`를 통한 파라미터 바인딩을 가능하게 해준다. 참고로 SQL Injection 공격을 예방하려면 PreparedStatement를 통한 파라미터 바인딩 방식을 사용해야 한다.
• 준비된 SQL을 커넥션을 통해 실제 데이터베이스에 전달한다. 참고로 executeUpdate()는 int를 반환하는데 이 값은 영향받은 Row수를 반환한다. 

이제 테스트 코드를 사용해서 이 코드를 사용해보자.

MemberRepositoryV0Test

package cwchoiit.jdbc.repository;

import cwchoiit.jdbc.domain.Member;
import org.junit.jupiter.api.Test;

import java.sql.SQLException;

import static org.junit.jupiter.api.Assertions.*;

class MemberRepositoryV0Test {

    private final MemberRepositoryV0 repository = new MemberRepositoryV0();

    @Test
    void save() throws SQLException {
        Member member0 = new Member("member0", 10000);
        repository.save(member0);
    }
}

실행 결과를 확인해보면, 데이터베이스에 정상적으로 데이터가 들어간 것을 확인할 수 있을 것이다.

JDBC 개발 - 조회

이번에는 JDBC를 통해 이전에 저장한 데이터를 조회하는 기능을 개발해보자.

MemberRepositoryV0 - 회원 조회 추가

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;
    }
}

• 여기서는, ResultSet이 등장했다. 조회의 경우 조회한 데이터를 보관하고 있는 녀석이 필요한데 그게 바로 이 녀석이다. 그리고 조회의 경우 executeQuery()를 사용한다. 데이터를 변경할땐 executeUpdate()를 사용했었다. 그래서 executeQuery()를 실행한 결과를 ResultSet에 담아서 반환한다. 그리고 이 녀석 역시 사용한 후엔 반납을 해야한다. 그런데, 사용하기 전에 PreparedStatement를 통해 파라미터 바인딩을 해줘야하기 때문에 같은 try-with-resources에 ResultSet을 묶을수가 없다. 그래서 내부에 한번의 try가 더 있다.
• rs.next()는 데이터베이스에 쿼리를 날려서 얻은 데이터에 대한 cursor를 다음으로 넘기는 메서드이다. 참고로 최초에는 커서가 데이터를 가리키고 있지 않기 때문에 최초에 한번은 호출을 해야 데이터를 조회할 수 있다. 아래 그림을 보자.

• 최초에는 커서가 데이터를 가리키지 않고 있다가 한번 호출을 하면 가장 처음 데이터를 가리킬 것이다. 그래서 데이터가 있다면 `true`를 반환한다. 그럼 데이터를 가져오면 된다. 
• rs.next()를 호출해서 커서가 다음 레코드로 이동했는데 데이터가 없으면 `false`를 반환한다. 
• findById() 메서드는 회원 한명을 조회한다. 따라서 조회 결과가 항상 1건이거나 0건이므로 while() 대신 if()를 사용해서 rs.next()를 호출한다. 그래서 최초에도 데이터가 없다면 이 ID를 가진 회원이 없다는 뜻이므로 NoSuchElementException을 발생시킨다.

테스트 코드에 이 메서드를 추가해보자!

package cwchoiit.jdbc.repository;

import cwchoiit.jdbc.domain.Member;
import lombok.extern.slf4j.Slf4j;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;

import java.sql.SQLException;

import static org.assertj.core.api.Assertions.*;
import static org.junit.jupiter.api.Assertions.*;

@Slf4j
class MemberRepositoryV0Test {

    private final MemberRepositoryV0 repository = new MemberRepositoryV0();

    @Test
    void save() throws SQLException {
        Member member = new Member("member2", 10000);
        repository.save(member);

        Member findMember = repository.findById(member.getMemberId());
        log.info("findMember = {}", findMember);

        assertThat(findMember).isEqualTo(member);
    }
}

실행 결과

13:37:46.054 [Test worker] INFO cwchoiit.jdbc.connection.DBConnectionUtil -- get connection = conn0: url=jdbc:h2:tcp://localhost/~/h2/db/jdbc user=SA, class = class org.h2.jdbc.JdbcConnection
13:37:46.060 [Test worker] INFO cwchoiit.jdbc.connection.DBConnectionUtil -- get connection = conn1: url=jdbc:h2:tcp://localhost/~/h2/db/jdbc user=SA, class = class org.h2.jdbc.JdbcConnection
13:37:46.062 [Test worker] INFO cwchoiit.jdbc.repository.MemberRepositoryV0Test -- findMember = Member(memberId=member2, money=10000)

• 테스트는 정상적으로 통과한다.
• 로그를 보면, 두개의 커넥션을 얻고 있음을 알 수 있다. 한번은 save(), 한번은 findById().
• 이러니까 커넥션 반납은 필수이고 굉장히 중요한 것이다. 커넥션은 한정적이라 계속 물고 있으면 고갈된다. 

JDBC 개발 - 수정, 삭제

수정과 삭제는 등록과 비슷하다. 등록, 수정, 삭제처럼 데이터를 변경하는 쿼리는 executeUpdate()를 사용하면 된다.

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;
    }
}

• executeUpdate()는 쿼리를 실행하고 영향받은 Row수를 반환한다. 여기서는 하나의 데이터만 변경하기 때문에 결과로 1이 반환된다. 만약, 회원이 100명이고, 모든 회원의 데이터를 한번에 수정하는 UPDATE 쿼리를 실행하면 결과는 100이 될 것이다.

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;
    }
}

• 위 업데이트와 쿼리만 DELETE로 달라질 뿐 나머지는 동일하다.

계속해서 사용했던 테스트 코드에 추가적으로 수정과 삭제를 넣어보자!

@Test
void save() throws SQLException {
    Member member = new Member("member4", 10000);
    repository.save(member);

    Member findMember = repository.findById(member.getMemberId());
    log.info("findMember = {}", findMember);

    assertThat(findMember).isEqualTo(member);

    repository.update(member.getMemberId(), 20000);
    Member updatedMember = repository.findById(member.getMemberId());
    assertThat(updatedMember.getMoney()).isEqualTo(20000);

    repository.delete(member.getMemberId());
    assertThatThrownBy(() -> repository.findById(member.getMemberId()))
            .isInstanceOf(NoSuchElementException.class);
}

• 실행 결과는 정상적으로 업데이트가 되고 삭제가 될 것이다.

정리

이렇게해서 JDBC를 통한 데이터베이스와 상호작용을 다시한번 리마인드해봤다. 현재 가장 핫한 ORM 기술인 JPA도 결국 내부적으로 JDBC를 사용하는 것이기 때문에 이 JDBC가 어떻게 동작하고 어떤 원리를 통해 데이터베이스에 접근해 커넥션을 가져오는지 이해하는게 중요하다. 결국 JDBC라는 표준 인터페이스를 구현한 각각의 데이터베이스마다 드라이버를 제공하고 그 드라이버를 라이브러리에 추가하면 JDBC가 자동으로 라이브러리에 추가된 드라이버를 인식하고 커넥션을 가져올 수 있는 드라이버를 찾는다. 이게 항상 말하지만 표준과 그것을 구현한 구현체의 위대함이다. 내가 데이터베이스를 변경하더라도 구현체만 갈아끼우면 되고 실제 클라이언트 코드는 변경할 필요가 없다. (물론 SQL은 데이터베이스마다 방언이라는게 존재하기 때문에 달라진다면 변경해야 겠지만)

자, 이제 JDBC를 다시 한번 리마인드했으니 이제 Connection Pool과 DataSource에 대해 공부할 차례다.

데이터베이스에서 빼놓을 수 없는 개념인 Index. 이 내용을 정리해보고자 한다. 

우선 다음과 같이 데이터베이스에 데이터가 저장되어 있다고 가정해보자.

그리고 질문은 다음과 같다.

Q: age = 20인 행을 찾으려면?

간단한 쿼리를 통해 가져올 수 있다.

SELECT * FROM XXX WHERE age = 20;

이 쿼리를 날리면 컴퓨터는 age가 20인 행을 찾기위해 모든 행을 하나씩 다 뒤지게 된다. 뭐 지금처럼 레코드가 5개만 있으면 1초도 안 걸린다. 근데 1억개가 넘게 있으면 또는 그 이상 있으면 있을수록 느리게 동작할 것이다.

그러다가 어떤 특이점에 도달하게 되면 데이터베이스는 굉장히 무시무시한 일이 일어날 수 있다. 그렇기 때문에 이러한 특이점이 일어나기 전 컴퓨터에게 도움을 줄 수 있는데 그게 바로 index다.

index가 어떻게 동작하는지 쉽게 이해하기 위해 다음 그림을 보자.

1부터 100까지 숫자가 있는 카드가 있다고 치자. A와 B가 게임을 하는거다. A가 카드 한장을 뽑으면 B가 맞추는 형식이다.

이 때 B는 A한테 1이야? 2야? 3이야? 4야? ... 100이야? 이렇게 순차적으로 물어보는게 효율적일까? 물론 뽑은 카드가 1이라면 그럴 수 있겠지만 뽑은 카드가 100이라면 절대 아니다. B는 A한테 이런식으로 질문해야 더 적은 질문으로 더 빠른 해답을 찾을 수 있다.

"50보다 커?" - "75보다 작아?" 이렇게 중간지점에서 대소를 비교하는 식으로 말이다.

데이터베이스도 이런식으로 질문을 하면 더 효율적이지 않을까? 맞다. 그러나 여기서 전제조건이 있다.

순서대로 정렬이 되어 있어야 저렇게 반씩 날릴 수 있는 질문이 가능하다라는 것. 

그래서, 데이터베이스에서도 저렇게 질문을 하고 싶다면 같은 컬럼을 복사해서 순서대로 정렬해 놓음이 필요하다.

그리고 이 정렬해서 복사해둔 컬럼을 index라고 부른다.

근데, 이 정렬하는 방식이 궁금하다. 정말 순서대로 저렇게 정렬해서 index를 만들까?

그렇다면 다음과 같이 그냥 Array나 Linked List로 순서대로 정렬해도 될 것 같다.

그런데 실제 데이터베이스들은 index를 만들 때 이렇게 만들지 않고 Tree 형태로 만든다. 뭐 이렇게 말이지.

즉, 모든 데이터들을 다 가져와서 일렬로 순서대로 정렬하는게 아니라, 아무렇게나 흩뿌려져 있는 데이터들을 가지고 와서 이렇게 가지치기 형식으로 정렬을 한다. 이렇게 해도 반으로 갈라낼수가 있기 때문이다. 예를 들어, 다음과 같은 질문을 받았다고 하자.

Q: 저는 5가 어디 저장되어 있는지 알고 싶어요.

1. 그럼 가장 상단에 있는 4한테 물어본다. 5는 4보다 큽니까? Yes 

2. 위 질문에 Yes가 나왔으니 오른쪽으로 빠진다. 그리고 만난 6한테 물어본다. 6보다 작습니까? Yes

두 번의 질문으로 원하는 답을 찾게 된다.

결론은 데이터베이스에서 index를 만들라고 하면 트리형태로 위 그림처럼 만들어준다는 얘기다.

이를 전문용어로 Binary Search Tree라고 한다.

근데, 저기서 조금 더 개선시킬 방법이 보인다. 저 하나 하나의 카드를 Node라고 부르는데, 이 노드에 숫자 하나만을 담는게 아니라 숫자를 두 개씩 넣어버리면 데이터가 많아지면 많아질수록 더 시원하게 날려버릴 수 있지 않을까? 다음 그림처럼 말이다. 

이렇게 한 노드에 여러 데이터를 넣어서 한번에 많은 양의 필요없는 데이터를 쳐낼 수 있다.

예를 들어 또 같은 질문이 들어왔다고 가정해보자.

Q: 저는 5가 어디 저장되어 있는지 알고 싶어요.

1. 4/8 이 들어있는 최상단 노드에 5보다 큰가?를 물어봤을 때 4는 No, 8은 Yes를 답하게 되니 중간 다리로 내려간다.

2. 6한테 5보다 작니?를 물어봤을 때 No를 답하니 5를 찾게 된다. 

데이터가 위 사진보다 더 많아졌음에도 불구하고 똑같이 2번의 질문만으로 답을 찾아낼 수 있게 된다.

근데, 여기서 또 다른 방식이 있다. B+Tree라는 구조인데 이건 다음과 같이 생겼다.

이 구조는 데이터는 전부 가장 밑바닥에 존재하고 (여기서 가장 하단의 노드를 가리키는 말로 '리프노드'라고한다) 가이드 라인만 제공하는 형식이다. 이렇게 되더라도 여전히 같은 맥락으로 절반씩 쳐내는 게 가능하다. 똑같이 2번의 질문 만으로 데이터를 찾아낼 수 있다.

근데 이 B+Tree의 다른점은 하단에 데이터끼리도 연결을 해 둔다는 것이다.

이렇게 하단에도 연결을 해두면 뭐가 좋을까? 범위 검색이 쉬워진다. 예를 들어 4부터 8까지의 데이터를 가져오고 싶으면 연결된 선으로 4부터 8까지 쭉 가져오기만 하면 된다. 4만 찾으면 말이지. B Tree랑 비교하면 훨씬 더 우월한 검색이 가능하다. B Tree로는 범위 검색 시 가지를 왔다리 갔다리 해야한다. 

정리를 하자면

age = 20인 데이터를 찾아줘!

• index가 없는 경우: 모든 행을 다 뒤져서 찾아냈을 때 돌려준다.
• index가 있는 경우: 자동으로 index 컬럼부터 보고 적은 질문으로 더 빨리 찾아낸다. 찾아낸 후 인덱스에는 원래 행을 찾을 수 있는 주소가 있는데 그 주소를 통해 찾고자 하는 데이터를 돌려준다.

그러나, index가 장점만 있지는 않다.

index를 구현하면 어떤 단점이 있나? 같은 내용을 담는 컬럼을 복사한다. 그 말은 데이터베이스의 용량을 더 사용한다는 의미이다.

즉, index가 많아지면 많아질수록 더 많은 데이터베이스의 용량을 가져다 사용한다는 뜻이다. 또 다른 단점은 만약 원래 데이터베이스에 레코드가 삽입, 수정, 삭제가 된다면? 그 레코드를 인덱스에도 똑같이 삽입, 수정, 삭제의 과정을 겪어야 한다. (근데, 요즘은 뭐 컴퓨터 성능이 너무 좋아서 사실 이런것까지 고려할 필요가 있나 싶다)

참고: PK는 index 생성이 필요없다. 왜냐하면 자동으로 정렬이 되어 있기 때문에. 그리고 이를 clustered index라고 표현한다.