해결된 질문
작성
·
338
1
안녕하세요 강의를 수강하다 제가 잘못 이해하고 있는 부분이 있는 것 같아서 질문드리게 되었습니다.
다음은 "간단한 주문 조회 V2: 엔티티를 DTO로 변환" 강의에서 35초에 해당하는 화면을 캡처한 부분입니다.
orderRepository는 @PersistenceContext 처리된 EntityManager를 가지고 있는데 이 때 Transaction의 범위가 어디까지인지를 잘 모르겠습니다.
추측으로는 List<Order> all가 준영속상태로 반환될 것으로 예상했는데 order가 membe프록시 객체를 가지고 있다가 Lazy 강제 초기화가 가능한 것을 보면 영속성 컨텍스트가 여전히 존재하는 상태인 것 같습니다.
Transaction의 범위가 어디까지인지 궁금합니다.
감사합니다.
답변 2
0
안녕하세요. 차성호님, 공식 서포터즈 코즈위버입니다. AI 답변에 더하여 답변 드립니다.
open-in-view 옵션이 기본적으로 활성화 되어있는데요, 이 상태라면 영속성 컨텍스트는 View 렌더링이 끝나는 순간까지 살아있게 됩니다.
이 옵션을 끈다면 @Transactional 어노테이션이 붙은 클래스 혹은 메서드가 끝날때까지 영속성 컨텍스트가 살아있습니다.
영속성 컨텍스트의 생명주기를 트랜잭션의 범위로 이해하시면 됩니다 :)
감사합니다.
0
안녕하세요, 인프런 AI 인턴이에요. 주문 조회 V2 강의에서 Transaction의 범위에 대한 질문이시군요.
@Transactional 어노테이션은 메소드나 클래스에 적용할 수 있으며, 해당 어노테이션이 적용된 메소드나 클래스 내에서 실행되는 모든 데이터베이스 접근 코드들은 하나의 트랜잭션 내에서 실행됩니다. 이렇게 하나의 트랜잭션 내에서 실행되는 코드들은 데이터베이스의 변경을 관리하고 롤백이 가능하게 해줍니다.
따라서, 주문 조회 V2에서 orderRepository를 사용하는 코드 내에서 실행되는 데이터베이스 접근 작업들은 하나의 트랜잭션 내에서 실행됩니다. 그리고 orderRepository를 사용하여 조회한 엔티티들은 영속성 컨텍스트에 저장되어 관리되며, 이 상태를 영속 상태라고 합니다.
주문 조회를 위해서는 order 에서 member로의 연관관계를 가져와야 합니다. 이때, 엔티티가 실제로 사용될 때까지 데이터베이스 조회를 지연시키기 위해 프록시 객체를 사용하며, 이때 member의 초기화는 프록시 객체를 통해 이루어집니다.
따라서, order 엔티티가 프록시 객체를 가지고 있고, Lazy 강제 초기화가 가능한 것은 영속성 컨텍스트가 여전히 존재하는 상태를 의미합니다. 이때 프록시 객체를 초기화하면 프록시 객체 대신 영속성 컨텍스트에 저장된 실제 엔티티가 반환됩니다.
요약하면, 주문 조회 V2에서 orderRepository를 사용하는 코드는 하나의 트랜잭션 내에서 실행되며, 조회한 엔티티들은 영속 상태로 관리됩니다. 이때, 프록시 객체를 통해 지연 로딩이 가능하며, 프록시 객체를 초기화하면 영속성 컨텍스트에 저장된 실제 엔티티가 반환됩니다.
더 자세한 내용은 해당 강의에서 다루고 있는 내용이니, 관련 커리큘럼을 따라 공부하시면 더 깊은 이해를 할 수 있을 거에요. 다른 궁금한 점이 있으시면 언제든지 물어보세요!
osiv를 모르고 있었네요.. 감사합니다!