트랜잭션 인터페이스, 트랜잭션 템플릿을 이용한 Service 계층의 Transaction 문제 해결

애플리케이션 구조 

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

컨트롤러 계층

• 웹 요청(request), 응답(response)를 관리하고 사용자 요청을 검증하는 역할
• 클라이언트가 접근하는 UI 관련된 기술인 웹, 서블릿, HTTP와 관련된 부분을 담당  
• 주로 Servlety과 HTTP 같은 웹 기술을 사용하고 MVC(Model + View + Controller)구조를 이루고 있습니다.

서비스 계층

• 비즈니스 로직을 담당하는 계층입니다.
• 특정 기술에 의존하지 않고 순수 자바코드로 작성

리포지토리 계층 

• 실제 DB에 접근하는 코드가 작성된 계층
• 주로 JDBC, JPA 를 사용합니다.

여기서 가장 중요한 계층은 서비스 계층입니다. 서비스 계층은 컨트롤러 계층과 리포지토리 계층의,특정 구현 기술에 직접 의존하게 되면 나중에 구현 기술이 변경될 때 영향을 받기 떄문에  가급적 비즈니스 로직만 구현하고 최대한 종속받지 않게 순수하게 유지되어야 합니다. 

서비스 계층을 순수하게 유지하려면 어떻게 해야할까요? 

 

이 전 포스팅에서 스프링을 사용하지 않고 트랜잭션 문제를 해결해보았었습니다. 잠깐 코드를 살펴보면

@Slf4j
@RequiredArgsConstructor
public class MemberServiceV2 {
    private final MemberRepositoryV2 memberRepository;
    private final DataSource dataSource;

    public void accountTransfer(String fromId, String toId, int money) throws SQLException {
        Connection con = dataSource.getConnection();
        try
        {
            con.setAutoCommit(false); // 트랜잭션 시작
            buisnesslogic(con, fromId, toId, money);
            con.commit();
        } catch (Exception e) {
            log.error("error detected!");
            con.rollback();
            throw new IllegalStateException(e);
        } finally {
            release(con);
        }
    }

• 서비스 계층의 계좌이체 로직을 보면 트랜잭션을 시작하고, 비즈니스 로직을 수행하고, 비즈니스 로직중 예외가 발생하면 롤백하고, 최종적으로 connection을 반납하는 작업까지 모두 한 로직(메소드)에서 구현되었습니다.
• 추가적으로 리포지토리 계층으로부터 올라오는 SQLException 또한 JDBC 기술에 의존합니다.
• 이렇게 서비스 계층에선 순수하게 비즈니스 로직만 수행해야 하는데 그렇지 못한 것을 볼 수 있습니다. 트랜잭션을 하기 위해 JDBC 기술(DataSource를 통한 커넥션 획득)을 사용하고 있어요.
• 이렇게 되면 만약 JDBC 기술에서 JPA 같이 다른 기술로 변경하게 되면 전체적인 서비스 계층의 코드를 수정해야 하는 문제가 발생합니다. 

 

정리하면 서비스 계층에서 총 3가지 문제가 있습니다. 

1. 트랜잭션 문제 : JDBC 구현 기술이 서비스 계층에 구현, 같은 트랜잭션을 사용하는 경우 커넥션을 파라미터로 넘겨 메소드를 만듦으로써 발생하는 오버로딩

 

2. JDBC 반복 문제 : try-catch-finally 와 커넥션을 받고 pstmt 사용해서 결과를 매핑, 실행의 반복 .. 

 

2. 예외 누수 문제 : Repository 계층으로부터 전파된 예외가 JDBC 기술을 의존하는 문제

 

이런 문제들은 스프링을 사용해서 서비스 계층을 순수하게 유지하면서 위에 기술한 문제들을 해결할 수 있습니다. 

---

Sol 1. 트랜잭션 추상화 - (Service 계층 TransactionManager) + (Repository 계층 Transaction Synchronize Manager)

현재 서비스 계층에서는 트랜잭션을 하기 위해 JDBC 기술에 의존하고 있습니다.

아예 다른 데이터 접근 기술인 JPA로 변경되는 경우 서비스 계층의 트랜잭션 관련 코드도 모두 함께 수정해야 합니다.

(JDBC은 con.setAutoCommit(false)으로 트랜잭션을 시작하지만, JPA는 transaction.begin()을 통해 트랜잭션을 시작)

 

이 문제를 해결하려면 트랜잭션 기능을 추상화 하면 됩니다.

 

스프링은 트랜잭션 추상화 기술을 이미 제공하고 있기 떄문에 이 기술을 사용해 서비스 계층에서 추상화에 의존하면 됩니다.

스프링이 제공하는 트랜잭션 인터페이스 PlatformTransactionManager

스프링이 제공하는 트랜잭션 추상화 기술의 인터페이스는 PlatformTransactionManager입니다.

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() : 트랜잭션을 시작
• commit() : 트랜잭션을 커밋
• rollback() : 트랜잭션을 롤백 

이제 추상화를 사용해 이제 DataSource를 의존하지 않고 서비스 계층에서 PlatformTransactionManager 인터페이스에 의존(외부에서 구현체 주입)해서 트랜잭션을 생성, 커밋, 롤백할 수 있습니다. 서비스 계층의 PlatformTranscationManager를 줄여서 트랜잭션 매니저라고 칭합니다.

 

 

추가로 리포지토리 계층에서 트랜잭션 매니저를 통해 생성된 커넥션을 사용하려면 트랜잭션 동기화 매니저를 사용해야 합니다. 

트랜잭션 동기화 매니저를 사용하는 방법은 간단합니다. 트랜잭션 매니저에 보관되어 있는 커넥션을 받아올 때 DataSourceUtils의 getConnection()을 사용하면 됩니다. 

// 트랜잭션 동기화 매니저를 사용하려면 DataSourceUtils를 통해 커넥션얻어야함.
Connection con = DataSourceUtils.getConnection(dataSource);

 

트랜잭션 동기화 매니저는 쓰레드 로컬이라는 기술을 사용해 커넥션을 동기화 해줍니다. 쓰레드 로컬은 멀티 쓰레드 상황에 안전하게 커넥션을 동기화 해주기 때문에, 서비스 계층에서 생성한 커넥션을 파라미터로 리포지토리 계층에 넘겨줄 필요가 없습니다!

 

위를 기반으로 한 서비스 계층과 리포지토리 계층의 코드를 살펴보겠습니다.

 

Service 계층 

@Slf4j
@RequiredArgsConstructor
public class MemberServiceV3_1 {
    private final PlatformTransactionManager transactionManager;
    private final MemberRepositoryV3 memberRepository;

    public void accountTransfer(String fromId, String toId, int money) throws SQLException 
    {
        // 트랜잭션 시작
        // 커넥션 생성
        TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());

        try
        {
            buisnesslogic(fromId, toId, money);
            transactionManager.commit(status);
        } catch (Exception e) {
            log.error("error detected!");
            transactionManager.rollback(status);
            throw new IllegalStateException(e);
        } // release는 transactionManager가 알아서 해줌.
	}

트랜잭션 매니저가 dataSource를 통해 커넥션을 생성해주는 덕분에 이제 서비스 계층에서는 dataSource를 의존할 필요가 없습니다.

트랜잭션 매니저의 구현체는 JDBC 기술을 사용하므로 DataSourceTransactionManager 구현체를 외부에서 주입합니다. 

(dataSource또한 JDBC 기술의 DriverManagerDataSource 구현체를 외부에서 주입합니다)

• transactionManager는 getTransaction()을 통해 트랜잭션을 생성하고, status를 리턴합니다. status에는 현재 트랜잭션의 상태가 포함되어 있어, 커밋, 롤백에서 필요합니다. 
  • getTransaction 내부 파라미터에 트랜잭션 관련 옵션을 지정가능. 여기서는 Default인 DefaultTransactionDefinition 객체를 사용

• transactionManager.commit(status) : 트랜잭션 커밋

• transactionManager.rollback(status) : 트랜잭션 롤백

Repository 계층

@Slf4j
@RequiredArgsConstructor
public class MemberRepositoryV3 {
    private final DataSource dataSource;
    
    private Connection getConnection() throws SQLException {

        // 트랜잭션 동기화 매니저를 사용하려면 DataSourceUtils를 통해 커넥션얻어야함.
        Connection con = DataSourceUtils.getConnection(dataSource);
        log.info("get connection = {}, class = {}",con,con.getClass());
        return con;
    }

    private void close(Connection con, Statement stmt, ResultSet rs)
    {
        JdbcUtils.closeResultSet(rs);
        JdbcUtils.closeStatement(stmt);

        // 트랜잭션 동기화 매니저를 사용하려면 DataSourceUtils 사용해야 함.
        // 트랜잭션을 사용하기 위해 동기화된 커넥션은 닫지 않고 유지.
        // 트랜잭션 동기화 매니저가 관리하는 커넥션이 없는 경우엔 해당 커넥션 닫음.
        DataSourceUtils.releaseConnection(con,dataSource);
    }

• 트랜잭션 매니저를 통해 생성된 커넥션은 트랜잭션 동기화 매니저에 보관됩니다!
• 동기화 매니저에 보관된 커넥션을 사용하기 위해서 DataSourceUtils의 getConnection(dataSource)를 사용합니다. (dataSource는 외부에서 DriverManagerDataSource 구현체를 주입받아 사용)  
• 커밋이나 롤백이후 최종적으로 커넥션은 반드시 DataSourceUtils의 releaseConnection 메소드를 사용해서 처리해 주어야 합니다. 이 메소드를 사용하면 동기화되어 있는 커넥션의 경우에는 커넥션을 닫지않고 유지하고, 트랜잭션이 끝난 경우(동기화 매니저가 관리하는 커넥션이 없는 경우)에는 커넥션을 닫아줍니다.

추상화한 인터페이스의 모든 구현체는 이 전과 마찬가지로 외부에서 주입합니다.

 

마지막으로 그림을 통해 전체적인 동작흐름을 살펴보겠습니다.

 

1. 트랜잭션 시작

1-1. 서비스 계층에서 transactionManager.getTransaction()을 호출해 트랜잭션 시작.

1-2. 트랜잭션 매니저에서 datasource를 사용해 커넥션 생성.

1-3. 커넥션을 수동 커밋 모드로 변경해서 트랜잭션을 시작.

1-4. 커넥션은 트랜잭션 동기화 매니저에 보관.

1-5. 트랜잭션 동기화 매니저는 쓰레드 로컬에 커넥션을 보관.

 

2. 비즈니스 로직

2-1. 비즈니스 로직에서 데이터 접근 로직을 호출.

2-2. 리포지토리 계층에서 트랜잭션 동기화 매니저에서 동기화된 커넥션을 조회.

2-3. 트랜잭션 동기화 매니저에서 리포지토리 계층에 커넥션을 던져줍니다.

2-4. 커넥션을 기반으로 SQL문을 실행.

 

3. 트랜잭션 종료

3-1. 트랜잭션을 커밋하거나 롤백함으로써 트랜잭션 종료

3-2. 트랜잭션 매니저에서 트랜잭션 동기화 매니저로부터 동기화된 커넥션을 획득

3-3. 획득한 커넥션을 통해 트랜잭션을 커밋 or 롤백합니다

3-4. 전체 리소스(트랜잭션 동기화 매니저의 쓰레드 로컬 정리, con.setAutoCommit(true)로 변경, con.close() 호출)를 정리합니다.

 

정리해보면

• 트랜잭션 추상화 덕분에 이제 JDBC 기술에 의존하지 않아 JDBC에서 JPA로 변경해도 서비스 코드를 그대로 유지할 수 있게 되었습니다. (기술 변경시 의존관계 주입만 DataSourceTransactionManager에서 JpaTransactionManager로 변경해주기만 하면 됨)
• 트랜잭션 동기화 매니저 덕분에 커넥션을 파라미터로 넘기지 않아도 되게 되었습니다.
• 위에 기술했던 1번 트랜잭션 문제는 해결했는데요. 아직  2번 JDBC 반복 문제와 3번 예외누수 문제가 남았습니다. 

---

Sol2. 트랜잭션 템플릿 사용 

Sol1의 트랜잭션을 사용한 서비스계층 살펴보면 

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

    // 트랜잭션 시작
    // 커넥션 생성
    TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());

    try
    {
        buisnesslogic(fromId, toId, money);
        transactionManager.commit(status);
    } catch (Exception e) {
        log.error("error detected!");
        transactionManager.rollback(status);
        throw new IllegalStateException(e);
    } // release는 transactionManager가 알아서 해줌.
}

try-catch-finally 형태 내에서 트랜잭션을 시작하고, 커밋/롤백하는데 이런 형태가 서비스 계층에서 반복되지 않게 스프링이 지원하는 템플릿 콜백 패턴(TransactionTemplate)을 사용해보겠습니다.

 

트랜잭션 템플릿 클래스

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

• excute() : 응답값이 있을 때 사용
• executeWithoutResult() : 응답값이 없을 때 사용

서비스 계층에서 이 템플릿 클래스를 사용해보겠습니다.

@Slf4j
public class MemberServiceV3_2 {

//    private final PlatformTransactionManager transactionManager;
    private final TransactionTemplate txTemplate;
    private final MemberRepositoryV3 memberRepository;

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

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

        // 트랜잭션 시작
        // 커넥션 생성
//        TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());
        txTemplate.executeWithoutResult((status)-> {
            try
            {
                buisnesslogic(fromId,toId,money);
            } catch (SQLException e) {
                throw new IllegalStateException(e);
            }
        });
    }

• TransactionTemplate을 사용하려면 transactionManager가 필요합니다. 따라서 생성자에서 transactionManager를 주입받으면서 템플릿을 생성했습니다.
• try-catch를 보면 트랜잭션을 생성하고, 커밋/롤백하는 부분들이 템플릿을 통해 실행함으로써 제거되었습니다.
• 트랜잭션 템플릿의 기본동작
  • 비즈니스 로직이 정상 수행되면 커밋.
  • Uncheck 예외가 발생하면 롤백. check 예외가 발생하면 커밋.
  • 코드에서 에외를 처리하기 위해 try-catch가 들어갔는데 비즈니스로직 수행중 SQLException 체크 예외를 넘겨주는데, 해당 람다에서 체크 체크 예외를 밖으로 던질 수 없기 때문에 언체크 예외(IllegalStateException)로 바꾸어 던지도록 예외를 전환했습니다.

<정리> 

• 트랜잭션 템플릿 덕분에 커밋, 롤백 작업을 깔끔하게 처리할 수 있었습니다.
• 하지만 여전히 이곳은 서비스 계층인데 비즈니스 로직 뿐만 아니라 트랜잭션을 처리하는 기술로직이 포함되어 있어 순수한 서비스 계층이라고 보기 어렵습니다.
• 서비스 로직에는 핵심 비즈니스 로직만 있어야 하지만 트랜잭션 기술을 사용하려면 어쩔 수 없이 트랜잭션 코드가 나와야 하는 딜레마가 있습니다.
• 다음 포스팅에서 트랜잭션 AOP를 사용해 해결해보도록 하겠습니다.

---

<참고자료>

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