처음 본 @Transactional

전 직장에서 NestJS - TypeOrm을 통해 개발을 진행해왔고, 퇴사 후 Spring에 한번 입문해보자는 생각으로 간단한 프로젝트를 진행 중입니다.

GitHub - One-armed-boy/spring_stream_video: 비디오 스트리밍 서버 with Spring boot

처음 구상했던 아주 기초적인 기능만 구현한 뒤 주변에 계신 스프링 개발자 분께 간단히 코드 리뷰를 받았는데, @Transactional 어노테이션의 활용에 대해 받은 리뷰가 특히 기억이 납니다.

이 때 아무래도 기존 TypeOrm 기반 트랜잭션 처리에 익숙해져있던 상황이고, Spring 컨텍스트에서 DB 관련 처리를 어떻게 수행하는지 전혀 모르던 상황이라 이에 대해 개인적으로 공부해보기 위해 해당 포스트를 작성합니다.

 

@Transactional이란

이는 Spring 등에서 간단히 어노테이션을 설정하는 것 만으로 편리하게 트랜잭션을 다룰 수 있게 해주는 주체입니다. 

이를 사용하면 등록된 메서드가 호출될 때 프록시를 통해 자동적으로 트랜잭션의 생명주기를 생성해주어 개발자는 트랜잭션 관리를 신경쓰지 않고 비즈니스 로직에 집중할 수 있다는 장점이 있습니다.

아래처럼 사용됩니다.

// 인터페이스 레벨에 설정
@Transactional
public interface TestService {
  // 인터페이스 메서드 레벨에 설정
  @Transactional
  public void add();
}

// 클래스 레벨에 설정
@Transactional
public class TestServiceImpl {
  // 클래스 메서드 레벨에 설정
  @Transactional
  public void add() {
    ...
  }
}

위 예시처럼 총 네가지 컨텍스트(인터페이스, 인터페이스 메서드, 클래스, 클래스 메서드)에서 활용할 수 있습니다.

이 때 적용 우선순위는 클래스 메서드 -> 클래스 -> 인터페이스 메서드 -> 인터페이스 순이 됩니다.

 

트랜잭션 전파 속성

Java Spring 환경이 익숙치 않은 저에게는 생소한 개념이었습니다.

다만 어떤 개념인지 감을 잡고나니 코드의 재사용성을 높여주는 좋은 기능이라는 생각이 들었습니다.

트랜잭션 전파 속성이란, 이미 생성된 트랜잭션 내부에서 다시 @Transactional 어노테이션이 붙은 메서드를 호출할 때 어떻게 처리할지에 대한 개념입니다.

만약 이미 @Transactional 어노테이션을 붙여둔 DML 서비스 로직 A가 있다고 가정합시다. 이 때 다른 서비스에서 해당 서비스의 DML 로직을 여러번 호출하고 한번이라도 실패했을 경우 모든 DML을 롤백하고 싶은 상황이 발생했을 때, 상위 트랜잭션이 A의 로직에 전파되지 않는다면 두 트랜잭션은 사실상 독립된 트랜잭션으로 여겨질테니 한번에 롤백할 수가 없어지고 이로 인해 A의 로직을 복붙해야하는 상황이 발생합니다.

트랜잭션 전파 설정을 통해 이러한 문제를 우아하게 해결할 수 있어지는 것입니다. 

전파 속성으로는 다양한 옵션을 줄 수 있는데, 몇개만 추리면 아래와 같습니다.

• REQUIRED: 이미 생성된 트랜잭션이 있다면 그에 참여하고, 그렇지 않다면 새로 트랜잭션 생성
• REQUIRES_NEW: 이미 생성된 트랜잭션의 유무에 관련 없이, 항상 새로운 트랜잭션 생성
• SUPPORTS: 이미 생성된 트랜잭션이 있다면 그에 참여하고, 그렇지 않다면 트랜잭션 없이 실행

 더 많은 옵션은 아래 링크에서 확인할 수 있습니다.

https://www.baeldung.com/spring-transactional-propagation-isolation#transaction-propagations

 

비즈니스 로직에 명시적 @Transactional을 붙여주는 이유

서론에서 언급한 코드 리뷰에서 저는, 왜 비즈니스 로직에 @Transactional 어노테이션을 붙여주지 않았냐는 질문을 받았습니다. 

그 때 제 논리는 아래와 같았습니다.

• 단일 쿼리는 어차피 DB 서버 측에서 하나의 트랜잭션으로 작용하는데, 굳이 트랜잭션을 명시적으로 처리해줄 필요가 있느냐
• 서비스 로직 전체에 적용하는 것은 불필요하게 트랜잭션의 길이를 길게 만드는 것 아닌가
• 여러 쿼리가 하나의 원자 단위로 작용해야할 때와, 서버 측에서 추가적인 검증을 통해 명시적으로 롤백해야하는 상황이 아니라면 굳이...?

이 글을 작성하고 있는 이 시점엔 생각이 바뀌었기 때문에 자문자답하는 식으로 위의 논리를 반박하겠습니다.

단일 쿼리는 어차피 DB 서버 측에서 하나의 트랜잭션으로 작용하는데, 굳이 트랜잭션을 명시적으로 처리해줄 필요가 있느냐

이 논리를 펼칠 당시 제가 몰랐던 사실은, JpaRepository 인터페이스를 상속한 Repository에서 이루어지는 기본적인 DA 작업은 명시적으로 전부 @Transactional이 붙어있다는 점입니다.

이는 JpaRepository의 실질적인 구현체인 SimpleJpaRepository(springframework.data.jpa.repository.support.SimpleJpaRepository) 클래스를 보면 알 수 있는데, 이에 구현된 DA용 메서드(ex. findAll, save 등)에는 모두 @Transactional이 이미 달려있습니다. 

SimpleJpaRepository 클래스의 소스코드 일부

따라서 제가 DB 서버 측에서 하나의 트랜잭션으로 자동 취급될 것이라고 이야기한 내용은 이미, 논의의 전제부터 잘못된 것입니다. 제가 @Transactional을 걸든말든, 애플리케이션 레벨의 명시적인 트랜잭션은 시작됩니다.

서비스 로직 전체에 적용하는 것은 불필요하게 트랜잭션의 길이를 길게 만드는 것 아닌가

항상 트랜잭션이 작은 크기를 유지하는 것은 중요합니다. 왜냐하면 트랜잭션이 시작하고 커밋되기까지 오래 걸리는 상황이 잦다면 DB 측 성능에 악영향을 줄 수 있기 때문입니다. (MVCC가 있다고 해도, 이를 위해 DB 서버 측에서 유지해야하는 리소스로 인해 악영향을 생길 수 밖에 없다.) 

이 문제로 인해 조금 고민을 해봤는데, 제 나름대로 내린 결론은 일반적인 경우에선 문제 없다는 것입니다. 이 상황에서 등장하는 일반적인 예시는 아래와 같습니다.

1. 트랜잭션 Start
2. 사용자 데이터 검증
3. DML 요청
4. 외부 API 요청(ex. 이메일 발송 등)
5. Commit

그리고 위 로직들은 간단히 UserService에서 어떤 한 메서드의 작동 방식이라 가정합시다. 이 때 올바른 트랜잭션 경계 설정의 예시는 아래처럼 기술되곤 합니다.

1. 사용자 데이터 검증
2. 트랜잭션 Start
3. DML 요청
4. Commit
5. 외부 API 요청(ex. 이메일 발송 등)

확실히 수정 전보다 더 나아보입니다. 그런데 이 경우, 선언적 트랜잭션을 통해선 UserService에서 구현하는게 어려워집니다. 그렇다면 프로그래밍 방식 트랜잭션으로 틀어야할까요?

제가 이 코드를 리뷰하는 상황이 온다면, 그보다는 UserService의 책임이 과도하다고 할 것 같습니다. 애초에 UserService가 마땅히 책임져야하는 부분이 바로 수정 후 트랜잭션으로 래핑된 로직이 아닐까 하구요. 그리고 위 전체 로직은 LoginFacade 같은 객체를 생성하여 거기에 책임을 부여하는 식으로 작업할 것 같습니다.

그리고 이를 조금 확장해서, 왠만한 경우에선 서비스 레이어에 선언적 트랜잭션을 걸어준다고 해도 성능 상 문제가 없으리라 결론 지었습니다. 

그리고 이 결론을 통하면 마지막 3번째 논리도 반박이 가능합니다.

여러 쿼리가 하나의 원자 단위로 작용해야할 때와, 서버 측에서 추가적인 검증을 통해 명시적으로 롤백해야하는 상황이 아니라면 굳이...?

그래서 명시적으로 붙여야 하는 이유는?

책임을 잘 분리한 서비스 레이어라면, 결국 해당 레이어에서 수행하는 비즈니스 로직들은 DB의 상태와 큰 관련이 있을 가능성이 큽니다. 따라서 명시적으로 @Transactional(readonly = true) 어노테이션을 붙여주는 것은 실제로 트랜잭션이 필요한 경우에서 실수할 가능성을 크게 줄여줄 것입니다. (위에서 이야기했듯이 붙인다고 크게 문제가 되는 것도 아니구요 ㅎㅎ)

※ 2024.02.04 추가

@Transactional이 서비스 레이어에 없을 경우, 영속성 컨텍스트와 엔티티 setter를 통한 자연스러운 애플리케이션 - DB 동기화가 불가능하고 명시적으로 영속성 컨텍스트를 관리해주어야 하는 문제도 있습니다.

 

후기

트랜잭션의 제네럴한 개념들(고립 레벨 같은)은 의도적으로 다루지 않았고 제가 몰랐던 자바 쪽 이야기를 위주로 다뤘습니다. 글을 작성하면서 Spring의 DB Access 파트를 같이 공부한 느낌인데, 보면 볼수록 잘 모르는 부분들이 계속 튀어나와서 좀 당황... (특히 영속성 컨텍스트 같은)

 

참고 문서

토비의 스프링 3.1 - 이일민 저

Why do I need Transaction in Hibernate for read-only operations?

 

@Transactional 바르게 알고 사용하기

 

Spring Transaction Best Practices - Vlad Mihalcea