LazyInitializationException: could not initialize proxy - no Session Error

📎 org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: ... entity.Folder.children could not initialize proxy - no Session

개인적으로 진행중인 프로젝트에서 JPA 연관관계 테이블의 조회 & 삭제 하는 과정에서 위와 같은 에러가 발생했습니다.

관련된 코드를 간단히 나타내면 다음과 같습니다.

(포스팅에서 틀린 내용이 있다면 피드백 주시면 감사하겠습니다. 🙌)

 

 

Folder 엔티티

@Entity
class Folder(
    ...
    
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "parent_id")
    @JsonBackReference
    var parentFolder: Folder?,
) : BaseTimeEntity() {

    @OrderBy("index asc")
    @OneToMany(mappedBy = "parentFolder", cascade = [CascadeType.ALL])
    @JsonManagedReference
    var children: MutableList<Folder>? = mutableListOf()

    @OneToMany(mappedBy = "folder", cascade = [CascadeType.ALL])
    var folders: MutableList<AccountFolder>? = mutableListOf()
    
    ...

Entity는 위와 같이 자신을 순환 참조로 부모 및 자식을 가지는 형식으로 구성되어 있는데요, 대댓글과 동일한 구조라고 생각하시면 됩니다.

 

 

Folder Conrtoller & Service

// Controller
@ApiOperation(value = "폴더 삭제(삭제하려는 폴더와 하위에 존재하는 모든 폴더 및 북마크들 삭제) API")
@DeleteMapping("/{folderId}")
fun deleteAllBookmarkAndAllFolderWithRelatedFolder(
    @PathVariable @ApiParam(value = "폴더 ID", example = "2", required = true) folderId: Long
): ResponseEntity<String> {

    // 에러가 발생하는 부분!
    val folder = folderService.findByFolderId(folderId)
    folderService.deleteFolderRecursive(folder)
    folderService.deleteFolder(folder)
    return ResponseEntity.status(HttpStatus.OK).body(Message.SUCCESS)
}


// Service
fun deleteFolder(folder: Folder) {
    folderRepository.deleteByFolder(folder)
}

fun deleteFolderRecursive(folder: Folder) {
    // Base Condition: 최하위 Depth의 폴더
    val children: MutableList<Folder> = folder.children ?: return

    children.let { folderList ->
        folderList.stream().forEach { folder ->
            deleteFolderRecursive(folder)
        }
    }

    bookmarkRepository.findByFolderId(folder.id!!)
        .let { list ->
            list.forEach {
                it.deletedByFolder()
                it.remindOff()
                bookmarkRepository.save(it)
            }
        }

    folderRepository.deleteByFolder(folder)
}

컨트롤러 및 서비스의 코드는 위와 같은데요, 폴더를 삭제할 시 자식의 모든 폴더 및 폴더에 존재하는 북마크들도 삭제가 되어야 합니다.

또한 스프링 트랜잭션의 Self Invocation 문제가 발생할 수 있다고 생각하였기에 두 개의 서비스 메서드를 컨트롤러에서 호출하도록 하였습니다.

 

Spring Transactional self invocation

• https://stackoverflow.com/questions/23931698/spring-transactional-annotation-self-invocation
• https://gmoon92.github.io/spring/aop/2019/04/01/spring-aop-mechanism-with-self-invocation.html
• https://velog.io/@park2348190/Spring-Transaction%EC%9D%98-Self-Invocation

 

실제 디버깅을 해보면 아래 코드에서 연관관계를 조회할 때 이미 예외가 발생하고 있습니다.

val folder = folderService.findByFolderId(folderId)

Unable to evaluate the expression Method threw 'org.hibernate.LazyInitializationException' ...

위 문제는 지연 로딩에서 현재 세션이 없기에 발생하는 오류인데요, 이를 해결하기 위해서는 JPA와 OSIV(Open Session In View)라는 개념에 대해 알아야 하기에 간략히 설명을 드리겠습니다.

 

 

JPA 영속성 컨텍스트

JPA에서는 영속성 컨텍스트라는 개념이 존재하는데요, 이는 엔티티를 영구 저장하는 환경 을 의미합니다.

 

애플리케이션 및 데이터베이스 사이에서 객체를 보관하는 가상의 데이터베이스 같은 역할을 합니다.

주로 사용하는 JPA의 경우 트랜잭션을 커밋하는 순간 영속성 컨텍스트에 새로 저장된 엔티티를 데이터베이스에 반영하는데, 이를 flush라고 합니다.

 

Entity의 생명주기로 비영속, 영속, 준영속 등이 존재하는데요 간략히 말씀드리면 다음과 같습니다.

• 비영속(new/transient): 영속성 컨텍스트와 전혀 관계가 없는 상태, Entity 객체를 생성하여도 영속성 컨텍스트에 저장하지 않은 상태
• 영속(managed): 영속성 컨텍스트에 저장된 상태, Entity가 영속성 컨텍스트에 의해 관리됨
• 준영속(detached): 영속성 컨텍스트에 저장된 후 분리된 상태

준영속 경우 영속성 컨텍스트에 저장된 경험이 존재하기에 비영속과는 달리 식별자가 존재한다는 것이 보장이 됩니다.

 

영속성 컨텍스트는 1차 캐시, 동일성 보장, 지연 로딩, 변경 감지(Dirty Checking) 등의 특징이 있는데요, 여기서는 따로 설명하지는 않겠습니다 ^^; 관련하여 궁금하시면 아래 링크를 참고해주세요. 😀

• https://www.baeldung.com/jpa-hibernate-persistence-context
• https://velog.io/@seongwon97/Spring-Boot-%EC%98%81%EC%86%8D%EC%84%B1-%EC%BB%A8%ED%85%8D%EC%8A%A4%ED%8A%B8Persistence-Context

 

 

트랜잭션 범위 및 영속성 컨텍스트

스프링 JPA의 경우 스프링 컨테이너가 제공하는 전략을 따르고 있는데요, 기본 전략으로 트랜잭션 범위의 영속성 컨텍스트 전략을 사용합니다. 이는 트랜잭션이 시작하는 순간 영속성 컨텍스트도 생성되고, 트랜잭션이 끝나는 순간 영속성 컨텍스트가 종료되는 전략 입니다.

따라서 트랜잭션이 동일할 경우 동일한 영속성 컨텍스트를 사용합니다.

// Service
@Autowired val repo1: Repository1
@Autowired val repo2: Repository2

@Transactional
fun logic() {
    repo1.save();
    repo2.save();
}

위와 같은 코드가 있을때 logic() 메서드에서 트랜잭션이 설정되어있기 때문에 repo1과 repo2는 동일한 영속성 컨텍스트를 사용합니다.

 

 

OSIV(Open Session In View)

OSIV(Open Session In View)란 JPA에서 영속성 컨텍스트와 Hibernate Session을 View가 렌더링이 될 때 까지 유지시키는 방법입니다.

스프링의 경우 보통 비즈니스 로직(Service Layer)에서 트랜잭션을 설정하고(@Transactional) 이 트랜잭션이 유지가 되는 영속성 컨텍스트의 범위는 뷰 렌더링까지는 되지는 않는데요, 따라서 위에처럼 Controller에서 Entity를 조회할 때 Lazy loading이 되어있다면 LazyInitializationException의 예외가 발생하게 됩니다.(현재 발생하고 있는 문제입니다.)

@Entity
class Folder(
    ...
    
    @ManyToOne(fetch = FetchType.Lazy)
    @JoinColumn(name = "parent_id")
    @JsonBackReference
    var parentFolder: Folder?,  // LazyInitializationException
) : BaseTimeEntity() {

    @Column
    var emoji: String? = ""

    @OrderBy("index asc")
    @OneToMany(mappedBy = "parentFolder", cascade = [CascadeType.ALL])
    @JsonManagedReference
    var children: MutableList<Folder>? = mutableListOf()
    
    @OneToMany(fetch = FetchType.EAGER, mappedBy = "folder", cascade = [CascadeType.ALL])
    var folders: MutableList<AccountFolder>? = mutableListOf()
    ...


// Controller
@ApiOperation(value = "폴더 삭제(삭제하려는 폴더와 하위에 존재하는 모든 폴더 및 북마크들 삭제) API")
@DeleteMapping("/{folderId}")
fun deleteAllBookmarkAndAllFolderWithRelatedFolder(
    @PathVariable @ApiParam(value = "폴더 ID", example = "2", required = true) folderId: Long
): ResponseEntity<String> {
    val folder = folderService.findByFolderId(folderId)
    folderService.deleteFolderRecursive(folder)
    folderService.deleteFolder(folder)
    return ResponseEntity.status(HttpStatus.OK).body(Message.SUCCESS)
}

 

 

OSIV = false(default) 일 때

// application.properties
spring.jpa.open-in-view=false

https://velog.io/@yebali/Spring-OSIV%EC%99%80-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94

 

 

OSIV = true 일 때

// application.properties
spring.jpa.open-in-view=true

https://velog.io/@yebali/Spring-OSIV%EC%99%80-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94

 

 

LazyInitializationException 해결방법

위 에러와 관련하여 여러 해결방법이 존재하는데요, 어떠한 방법이 Best Practice인지는 상황에 따라 다를 것 같습니다.

 

 

1. Entity의 FetchType을 Lazy -> Eager로 수정

위에서 연관관계로 설정되어 있는 Entity에서 Lazy를 Eager로 설정합니다.

참고로 JPA에서 default Fetch 전략은 다음과 같습니다.

• OneToMany: Lazy
• ManyToOne: Eager
• ManyToMany: Lazy
• OneToOne: Eager

@Entity
class Folder(
    ...
    
    @ManyToOne
    @JoinColumn(name = "parent_id")
    @JsonBackReference
    var parentFolder: Folder?,  // LazyInitializationException
) : BaseTimeEntity() {

    @Column
    var emoji: String? = ""

    // FetchType을 Lazy에서 Eager로 변경
    @OrderBy("index asc")
    @OneToMany(fetch = FetchType.Eager, mappedBy = "parentFolder", cascade = [CascadeType.ALL])
    @JsonManagedReference
    var children: MutableList<Folder>? = mutableListOf()
    
    // FetchType을 Lazy에서 Eager로 변경    
    @OneToMany(fetch = FetchType.EAGER, mappedBy = "folder", cascade = [CascadeType.ALL])
    var folders: MutableList<AccountFolder>? = mutableListOf()
    ...

~ToOne의 경우 deafult로 Eager이기에 ~ToMany만 Lazy에서 Eager로 수정합니다.

 

그 후 디버깅을 통해 값을 확인해보면 위에서 발생했던 LazyInitializationException 예외가 발생하지 않는 것을 확인할 수 있습니다.

Lazy에서 Eager로 변경하였기에, 연관 관계 설정이 되어있는 Entity까지 모두 가져온다는 단점이 있습니다.

 

 

2. OSIV = true로 설정

위에서 OSIV에 대해 간략히 말씀드렸는데요, OSIV를 true로 설정하여 영속성 컨텍스트와 Hibernate Session을 View가 렌더링이 될 때 까지 유지시키면 Controller에서 Entity를 조회할 때 Lazy Loading이더라도 에러가 발생하지 않습니다.

// application.properties
spring.jpa.open-in-view=true

OSIV를 true로 설정한 후 확인해보면 예외 없이 작동하는것을 확인할 수 있습니다.

하지만 OSIV의 경우 Anti-Pattern인 듯 하며 성능적인 문제에도 이슈가 발생할 수 있다고 합니다. 따라서 OSIV=true는 어드민이나 내부 전용 사이트 등 중요도가 떨어지는 프로젝트에 사용하는 것을 권장하고 있습니다.

추가적인 내용은 아래 링크를 참고해주세요.

• https://stackoverflow.com/questions/30549489/what-is-this-spring-jpa-open-in-view-true-property-in-spring-boot
• https://github.com/spring-projects/spring-boot/issues/7107

 

 

3. Controller에서 Lazy Loading의 Entity를 조회하지 않기

개인적인 생각으로는 가장 이상적인 방법인 듯 합니다. 트랜잭션 안에서 지연로딩을 조회할 수 있기 때문에 트랜잭션이 설정되어 있는 비즈니스 로직 내에서 Entity를 조회하면 위와 같은 문제가 발생하지 않습니다.

    // Service
    fun deleteFolderWithChild(folderId: Long) {
        val folder = folderRepository.findById(folderId).orElseThrow { folderNotFoundException }
        folderRepository.deleteByFolder(folder)

        val children: MutableList<Folder> = folder.children ?: return
        
        ...
        
    }

위 처럼 Controller가 아닌 비즈니스 로직이 작성되어 있는 Service에서 Entity를 조회한 후 로직을 처리하면 정상적으로 동작이 됩니다.

 

 

4. Use JOIN FETCH in JPQL

위 방법은 직접 해보지는 않았으나, JPQL에서 JOIN FETCH를 통해서도 문제를 해결할 수 있다고 합니다.

SELECT f FROM Folder f
	JOIN FETCH f.parentFolder
    JOIN FETCH f.children
    JOIN FETCH f.folders

+ 위와 같이 JOIN FETCH를 여러개 사용할경우 아래와 같은 에러가 발생할 수 있는데요, 아래와 같이 발생할경우 List를 Set으로 변경해주면 해결할 수 있습니다.

"MultipleBagFetchException: cannot simultaneously fetch multiple bags is there a workaround"

 

 

 

결론

해당 문제로 구글링을 해보면 대부분 @Transactional 설정, Fetch를 Eager로 변경 의 방법이 대부분이었는데요, 이번 기회에 좀 더 찾아보면서 헷갈렸던 OSIV의 개념이나 자주 까먹는 JPA의 Fetch default 전략 등 다시 한번 학습할 수 있어서 좋았습니다.

 

혹시 위와 같은 문제가 아닐경우 트랜잭션 내에서 지연로딩을 하고 있는지 확인해주시면 좋을 것 같습니다.

 

 

 

참고 문서

• https://stackoverflow.com/questions/30549489/what-is-this-spring-jpa-open-in-view-true-property-in-spring-boot
• https://ttl-blog.tistory.com/183
• https://www.baeldung.com/hibernate-initialize-proxy-exception
• https://stackoverflow.com/questions/23931698/spring-transactional-annotation-self-invocation
• https://gmoon92.github.io/spring/aop/2019/04/01/spring-aop-mechanism-with-self-invocation.html