@Transactional 썼지만 Dirty Checking 이 안된 이유

목차

0. Dirty Checking 이 동작하지 않은 내 코드

1. Dirty Checking 은 어떤 조건에서 실행되는가?

2. @Transactional 은 어떤 원리로 Dirty Checking 을 진행하는가?

3. 그럼 어떻게 수정해야하나?

4. 결론

 

 

Dirty Checking 과 @Transactional 의 원리를 잘 아시는 분이라면 이 글에서 얻어가시는게 많이 없을 수 있습니다. 이 글은 무지성으로 @Transactional 을 사용한 지난 날을 반성하고 더 공부하기 위해 작성했습니다.

 

0. Dirty Checking 이 동작하지 않은 내 코드

너무 부끄럽지만 처음엔 이렇게 코드를 짜놓고 왜 Dirty Checking 이 되지 않는지 의아했다.

@Transactional 어노테이션이 있는 상태에서 User 의 property 를 수정했으니 당연히 수정되어야 하는거 아닌가?

user는 데이터베이스에서 조회한 엔티티를 외부에서 인자로 주입했다.

 

@Component
@RequiredArgsConstructor
public class JwtTokenProvider {

    private final UserRepository userRepository;

    @Transactional
    public void saveRefreshToken(User user, String newRefreshToken) {
	...
        user.setRefreshToken(newRefreshToken);
        ...
    }
}

그럼 여기서 내가 해볼 수 있는 질문은 2가지다.

 

1. Dirty Checking 은 어떤 조건에서 실행되는가?

2. @Transactional 은 어떤 원리로 Dirty Checking 을 진행하는가?

 

위 2가지 물음의 답을 차례대로 풀어보겠다.

 

1. Dirty Checking 은 어떤 조건에서 실행되는가?

우선 Dirty Checking 이 무엇인지 알아보자.

Dirty Checking 는 어플리케이션 내부 엔티티의 변화를 추적하기 위해 ORM에서 사용되는 개념으로, 변화를 감지하고 트랜잭션이 commit 되면 수정 사항을 DB에 자동으로 반영하는 것을 의미한다.

 

그럼 Dirty Checking 은 언제 실행될까?

Dirty Checking 은 트랜잭션 쓰기 연산 중 영속성 컨텍스트(Persistent Context) 가 엔티티의 변경을 감지할 때 자동으로 실행된다.

JPA에서는 엔티티를 조회하면 해당 엔티티의 조회 상태 그대로 스냅샷을 만들어두는데, 이 스냅샷의 상태와 비교하여 변경사항이 있다면 오염(Dirty)이 감지(Checking) 됐다고 판단한다. 즉 최초 조회한 상태와 다를 때 Dirty Checking 이 감지된다.

 

영속성 컨텍스트 라는 단어가 등장했다. 영속성 컨텍스트란 JPA 런타임 환경으로 엔티티의 수명주기 및 DB 영속성을 관리하는 역할을 맡는다. 쉽게 말해 엔티티의 영구 저장 환경이자, 애플리케이션과 DB 사이에서 객체를 보관하는 논리적 개념이라 할 수 있다. 영속성 컨텍스트라는 엔티티 영구 저장 환경이, 엔티티의 변경을 감지한다면 Dirty Checking 이 이뤄진다고 볼 수 있다.

정리하자면, 엔티티가 영속성 컨텍스트의 관리를 받을 때 Dirty Checking 은 실행된다.

그렇다면 이 영속성 컨텍스트라는 것은 어느 타이밍에 등장하는 것일까? 이 질문에 대한 답은 @Transactional 이 가지고 있다.

 

2. @Transactional 은 어떤 원리로 Dirty Checking 을 진행하는가?

@Transactional 은 트랜잭션의 시작과 종료 지점을 구분하는 트랜잭션 경계를 선언할 때 사용된다.

@Transactional이 붙은 메서드가 호출되면 JPA 는 새로운 트랜잭션을 생성하여 영속성 컨텍스트와 연결시킨다.

트랜잭션의 종료지점은 해당 트랜잭션이 commit 되는 시점으로도 볼 수 있는데, 이 커밋 시점에 영속성 컨텍스트는 트랜잭션 쓰기 작업에 해당되는 Query를 생성한다. 즉 해당 트랜잭션 내부에서 영속성 컨텍스트가 엔티티의 변화를 감지하면 수정사항에 맞는 Query 문을 생성한다.

 

여기서 중요한 점은 영속성 컨텍스트가 모든 엔티티의 변화를 감지(Drity Checking)하지 않는다는 점이다.

엥? 그럼 어떤 엔티티의 변화만 감지하는 것일까? 바로 영속성 컨텍스트가 관리하는 엔티티, 즉 영속 상태의 엔티티만 Dirty Checking 의 대상이 된다. 엔티티에겐 4가지 상태(비영속, 삭제, 영속, 준영속)가 있고, 영속 상태의 엔티티란 쉽게 말해 DB에 저장되어 있는 데이터라 할 수 있다.

 

다시 코드로 돌아와보자.

Dirty Checking 의 대상이 되고자 하길 바랬던 엔티티 User 는 분명 DB로부터 조회한 객체다. 하지만 이를 영속 상태의 엔티티라고 할 수 없다. 왜냐? 해당 엔티티는 @Transactional 외부에서 주입된, 즉 현재 메서드의 영속성 컨텍스트와 관련없는 엔티티이기 때문이다.

 

@Component
@RequiredArgsConstructor
public class JwtTokenProvider {

    private final UserRepository userRepository;

    @Transactional // 해당 트랜잭션 경계와 연결되는 영속성 컨텍스트와 무관한 user 엔티티 
    public void saveRefreshToken(User user, String newRefreshToken) {
	...
        user.setRefreshToken(newRefreshToken);
        ...
    }
}

 

- 준영속: Detach 된 엔티티

- 비영속 : DB에 반영되기 전 처음 생성된 엔티티

 

위 두 상태의 엔티티는 Dirty Checking 의 대상이 아니다. 그렇기 때문에 위 코드에서 메서드에 @Transactional 을 붙이고 user 의 값을 변경해도 DB에 반영되지 않는 것이다.

 

인자로 주입받는 user 엔티티는 4가지 상태 중 준영속 상태로, DB에는 저장돼 있으나 영속성 컨텍스트에서는 분리된 상태다.

어떤 영속성 컨텍스트? 바로 saveRefreshToken() 의 트랜잭션 경계와 연결된 영속성 컨텍스트!

정리하면 @Transactional 의 Dirty Checking 대상은 영속 상태의 엔티티에 한정되며, 여기서 언급한 영속 상태의 엔티티는 해당 트랜잭션과 연결된 영속성 컨텍스트가 관리하는 엔티티를 의미한다. 이를 제외한 엔티티(user)의 변경에는 해당 사항이 없다!

 

3. 그럼 어떻게 수정해야하나?

간단하다. saveRefreshToken() 을 호출하는 상위 계층에서 User 를 조회하지 않고, saveRefreshToken 메서드 내부에서 user 엔티티를 조회하면 된다. 왜? 영속 상태의 엔티티만 Dirty Checking 이 적용되기 때문이지. 수정된 코드는 아래와 같다.

@Component
@RequiredArgsConstructor
public class JwtTokenProvider {

    private final UserRepository userRepository;

    @Transactional
    public void saveRefreshToken(String refreshToken, String something) {
	...
        User user =  userRepository.findUserBySomething(something);
        user.setRefreshToken(refreshToken);
        ...
    }
}

 

 

4. 결론

돌이켜 보면 내가 잘못한 점은 2가지다.

0. 코드를 그지같이

1. @Transactional 원리와 Dirty Checking 조건을 파악하지 못한 점

2. UserRepository 의존성을 생각하지 않고 코드를 짠 점

 

실컷 Dirty Chekcing과 @Transactiona 에 관한 글을 썼지만 두번째 원인은 '의존성'이다. UserRepository 를 어디서 사용할지 의존성을 잘 고려하는 코드를 짰다면 상위 계층에서 user 를 인자로 넘기지 않았을 것이다. 그랬다면 영속 상태의 엔티티에 @Transactional 이 적용되어 Dirty Checking 도 잘 동작했겠지.

뭐든 기본이 중요함을 느끼는 사건이었다.