[jdbc] 트랜잭션 관리 (feat. 스프링 프레임워크)

📑 이전 글: 트랜잭션

✅ 자바 애플리케이션에서 트랜잭션 관리

트랜잭션은 비지니스 로직이 있는 서비스 계층에서 시작해야 한다.

비지니스 로직에서 문제가 생기면, 문제가 생긴 부분으로 인해 실행취소되어야 하는 작업들은 전부 롤백해야하기 때문이다.

 

트랜잭션을 시작하려면 Connection이 있어야 한다!

서비스 계층에서 트랜잭션을 유지하려면

서비스 계층에서 커넥션을 만들고, 트랜잭션에 끝날 때까지 동일한 커넥션을 유지해야 한다.

 

📌 문제점

유지보수를 위해서는 하나의 클래스가 변경될 때 나머지 클래스들의 변경이 최소화되어야 한다.

 

즉 UI가 바뀌고, 데이터 저장 기술이 바뀐다고 하더라도

핵심 비지니스 로직인 서비스 계층은 최대한 수정되지 않아야 한다.

 

그런데 트랜잭션을 서비스 계층에서 시작해버리면

서비스 계층은 jdbc 기술에 의존하게 된다.

 

🚀 코드 예시

@RequiredArgsConstructor
public class MemberService {

    private final DataSource dataSource; // <- jdbc 기술
    private final MemberRepository memberRepository;

    public  void accountTransfer(String fromId, String toId, int money) throws SQLException {
        Connection conn = dataSource.getConnection(); // <- jdbc 기술
        try {
            conn.setAutoCommit(false); // 트랜잭션 시작
            
            // 계좌이체 작업 (코드 생략)
            
            conn.commit(); // 성공 시 커밋

        } catch (Exception e) {
            conn.rollback(); // 실패 시 롤백
            throw new IllegalStateException(e);
        } finally {
            release(conn);
        }

    }
    
    ...
    
}

 

이렇게 되면, 리포지토리가 jdbc 기술을 사용하지 않게 된다면

DataSource, Connection, SQLException 또한 사용하지 않게 될테니

이 부분들을 전부 수정해주어야 한다는 문제가 발생한다.

 

한마디로 핵심 비지니스 로직과 jdbc 기술이 섞여있어서, 유지보수가 힘들어진다.

그리고 코드의 중복도 많아진다. (나머지 서비스 메서드들에서도, 위 코드에서 생략된 계좌이체 작업 부분(=실제 비지니스 로직 부분)을 제외하고는 모든 코드가 거의 똑같을 것이다!)

 

✅ Spring framework에서는 해결방법을 제공한다.

스프링은 TransactionManager 인터페이스를 제공함으로써 트랜잭션 기능을 추상화하고 있다.

 

TransactionManager의 하위 인터페이스인 PlatformTransactionManager 인터페이스는

jdbc 기술에 대한 트랜잭션을 추상화하고 있고, 스프링은 jdbc 드라이버에 따른 구현체들을 제공한다.

 

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

 

이 트랜잭션 매니저는 ThreadLocal을 사용해서 커넥션을 유지할 수 있도록 해주기 때문에,

멀티쓰레드 상황에서 안전하게 커넥션 동기화가 가능하다.

 

대표적 구현체로는 DataSourceTransactionManager가 있다.

 

📌 DataSourceTransactionManager 동작 방식

- Datasource를 통해 커넥션을 생성하고 트랜잭션을 시작한다.

- 해당 커넥션을 트랜잭션 동기화 매니저에게 보관한다. (코드를 뜯어보니 ConnectionHolder가 이 역할을 하는것같은데 더 공부해봐야겠다)

- 리포지토리는 트랜잭션 동기화 매니저가 보관하고 있는 커넥션을 꺼내서 사용한다.

- 트랜잭션이 종료되면 DataSourceTransactionManager는 해당 커넥션을 종료하고, 커넥션을 반환한다.

 

 

✅ TransactionTemplate은 코드 중복 문제를 해결해준다.

 

TransactionManager를 통해 트랜잭션을 추상화하더라도 코드 중복 문제는 여전히 존재한다.

스프링 프레임워크에서는 이것을 해결해주는 TransactionTemplate 클래스를 제공한다.

(템플릿 콜백 패턴)

 

🚀 코드 예시

@RequiredArgsConstructor
public class MemberService {

    private final TransactionTemplate transactionTemplate;
    private final 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);
            }
        });

    }
    ...
}

 

 

📌 여전히 해결되지 않는 문제점

여전히 서비스 계층에 트랜잭션 처리 로직이 포함되어 있다.

하나의 클래스에서 '비지니스로직', '트랜잭션처리' 라는 두 가지 관심사를 처리하게 된다.

결과적으로 유지보수가 힘들어진다.

 

그래서 스프링 프레임워크에서는 트랜잭션 AOP를 제공한다.

 

✅ @Transactional

스프링에서 제공하는 트랜잭션 AOP이다.

트랜잭션이 필요한 클래스나 메서드에 이 어노테이션을 붙이면,

스프링의 트랜잭션 AOP가 트랜잭션 프록시를 적용해준다.

 

📌 트랜잭션 프록시

트랜잭션 처리 기능을 대신 수행해주는 객체이다.

트랜잭션 프록시가 트랜잭션 시작, 서비스 클래스의 비지니스 호출, 커밋 또는 롤백, 커넥션 반납을 대신 해주기 때문에

서비스 클래스의 메서드에는 비지니스 로직만 구현해두면 된다.

(이때 서비스 클래스의 메서드는 트랜잭션 프록시에서 호출할 수 있도록 모두 public으로 구현해야 한다)