레포지토리 계층에서의 트랜잭션에 대한 의문

[질문 템플릿]
1. 강의 내용과 관련된 질문인가요? 예
2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예
3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예

[질문 내용]
본래 DB에 쿼리를 날리는 행위는 트랜잭션 안에서 이루어져야하는데

본 강의부터 뒤쪽 강의까지 컨트롤러단에서 직접 레포지토리 메서드를 호출하여 코드를 작성하는걸 볼 수 있습니다.

제가 알아본 바로는 아래와 같다고 합니다.

쓰기 작업: 반드시 트랜잭션 필요.
조회 작업: 트랜잭션 없어도 가능. 단, 지연 로딩 시 트랜잭션 없으면 예외 발생.
실무 규칙: Repository는 트랜잭션 안 열고, Service 계층에 @Transactional로 비즈니스 단위 트랜잭션 관리.
읽기 전용 조회 최적화: @Transactional(readOnly = true) 사용 → 성능 최적화 + 예외 방지.

근데 뒤쪽 강의에서는 fetch join을 사용하니 지연 로딩에 대한 예외가 발생안한다고 쳐도

현재 이 강의 초반에 /api/v1/simple-orders 에 대한 메서드에서는 실제로 지연 로딩에 의한 쿼리를 호출합니다.

그렇다면 결국 트랜잭션이 없는 상태에서 이루어진 것이니

LazyInitializationException 예외가 발생해야하는거 아닌가요?

그리고 보통 실무에서 컨트롤러에서 fetch join 쿼리 메서드(트랜잭션이 걸려있지 않은) 등을 레포지토리에서 바로 호출하는 경우가 흔한가요?

안녕하세요, 인프런 AI 인턴입니다. JHL님.

현재 질문 주신 내용은 JPA에서의 트랜잭션 사용과 지연 로딩 관련된 주제입니다. 실제로 JPA는 데이터를 변경할 때는 트랜잭션이 필수지만, 단순 조회에서는 트랜잭션 없이도 작동이 가능합니다. 그러나 지연 로딩(Lazy Loading)을 사용하는 경우, 트랜잭션이 없으면 LazyInitializationException이 발생할 수 있으며, 이를 방지하기 위한 방법으로 Fetch Join을 사용합니다. Fetch Join을 사용하면 Entity를 조회할 때 관련된 Entity도 함께 조회하여 지연 로딩 문제를 해결할 수 있습니다.

그렇기에 /api/v1/simple-orders 관련 메서드에서는 Fetch Join을 사용해 지연 로딩 문제를 피한 것이라고 볼 수 있습니다.

Fetch Join의 장점: 지연 로딩을 회피하여 발생할 수 있는 예외를 방지하고, 성능 최적화를 꾀할 수 있습니다.

또한, 컨트롤러에서 직접 레포지토리 메소드를 호출하는 것은 간단한 조회에 한정되며, 실무에서는 트랜잭션 관리가 필요한 로직은 서비스 계층을 통해 처리하는 것이 일반적입니다.

관련하여 다른 학습자 분들의 질문과 답변이 아래 링크에서 확인 가능합니다:

트랜잭션 관련 질문 - 간단히 살펴보면 트랜잭션이 없더라도 단순 조회는 가능하지만 지연된 로딩 시에는 예외가 발생할 수 있음을 설명합니다.
JPA 조회시 트랜잭션 관련 문의입니다. - 지연 로딩 예외 발생 상황에 대해 다른 학습자의 질문이 있습니다.

이해 도움이 되었길 바라며, 질문 주신 사항에 대해 더욱 자세한 정보가 필요하시면 추가 문의 부탁드립니다. 곧 지식공유자께서 더 구체적인 답변을 드릴 것입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변