[디버깅] org.hibernate.LazyInitializationException: could not initialize proxy - no Session 에러메세지가 뜨는 이유와 해결 방법 🤔

 

캡스톤 프로젝트를 하는 도중

다음과 같은 에러 메세지가 발생했다.

 

왜 발생하며

어떻게 해결하는지 같이 알아보도록 하자.

 

---

우선 이 에러의 경우

test 케이스에서 발생한 에러이다.

 

실행 메서드

 

우선 필자가 현재

이용하고 있는 테이블 구조는 다음과 같다.

 

테이블 구조

 

n:m 연관관계 매핑에서 Reply라는

매핑 테이블이 생성되고

특정 디자인의 댓글을 찾아오는 메서드를 실행하고 있다.

 

실행하면

에러 메세지

 

다음과 같은 에러가 발생한다.

 

우선 이 에러가 발생하는 이유는 다음과 같다.

 

🤔

Reply 클래스의 Member에 대한 Fetch 방식이 LAZY이기 때문에

한 번에 Reply 객체와 Member 객체를 조회할 수 없기 때문에 발생한다.

 

---

 

👉 해결방법은 두 가지이다.

1. @Query를 이용해서 조인 처리하기

2. @EntityGraph를 이용해서 Reply 객체를 가져올 때 Member 객체를 로딩하기

 

 

@EntityGraph는 엔티티의 특정한 속성을 같이 로딩하도록 표시하는 어노테이션이다.

 

JPA를 이용하는 경우에는 연관관계의 FATCH 속성값을 LAZY로 지정하는 것이 일반적이다.

@EntityGraph는 이러한 상황에서 특정 기능을 수행할 때만 EAGER 로딩을 하도록 지정할 수 있다.

 

---

@EntityGraph는 attributePaths 속성과 type 속성을 가지고 있다.

- attributePaths : 로딩 설정을 변경하고 싶은 속성의 이름을 배열로 명시한다.

- type : @EntityGraph를 어떤 방식으로 적용할 것인지를 설정한다.

- FATCH 속성값은 attributePaths에 명시한 속성은 EAGER로 처리하고, 나머지는 LAZY로 처리한다.

- LOAD 속성값은 attributePaths에 명시한 속성은 EAGER로 처리하고,

나머지는 엔티티 클래스에 명시되거나 기본 방식으로 처리한다.

 

즉, Reply를 처리할 때 @EntityGraph를 적용해서 Member도 같이 로딩할 수 있도록 변경하면 된다.

 

 

ReplyRepository를 다음과 같이 변경해준다.

 

ReplyRepository

 

변경하고 나면

다음과 같이 test코드가 정상적으로 동작하는 것을

확인할 수 있다.

 

정상 실행 화면

 

오늘도 에러를 해결함으로써 성장했다.

 

더욱더 열심히 공부하자! 🔥