[JPA] JPA Auditing과 em.merge()의 동작 원리 살펴보기 - 테스트에서 id 값을 주의하자

🌱 들어가기 전

옛날에 썼던 글인데, 요즘 블로그를 너무 안 쓴 것 같아서 오랜만에 올리는 글 😶

혼자 공부할 겸 작성한 글이었어서 다소 설명이 부족합니다...! 

---

 

🌱 엔티티 소개

@Entity
@EntityListeners(AuditingEntityListener.class)
public class User {

    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)
    @CreatedDate
    private LocalDateTime createdAt;

    @LastModifiedDate
    private LocalDateTime updatedAt;

 

User 클래스는 사용자에 대한 엔티티이며, id 전략은 IDENTITY이다.

이때, createdAt, updatedAt에 대해서 JPA auditing 기능을 사용한 것을 볼 수 있다.

우리는 사용자 엔티티에 대한 저장을 위해서 간단한 테스트 코드를 작성해볼 예정이다.

 

public class UserTest {
    public static final User JAVAJIGI = new User(1L, "javajigi", "password", "name", "javajigi@slipp.net");
    public static final User SANJIGI = new User("sanjigi", "password", "name", "sanjigi@slipp.net");
}

요 클래스는 테스트에서 사용할 간단한 픽스처이다.

여기서 JAVAJIGI에 대해서는 id 값이 초기화가 되어 있고, SANJIGI 변수에 대해서는 id 값이 초기화 되어 있지 않은 상태임을 유의하자.

 

---

 

🌱 문제 상황

@Test
@DisplayName("유저를 저장한다.")
void save1() {
	final User actualUser = userRepository.save(UserTest.JAVAJIGI);

	assertThat(actualUser).usingRecursiveComparison()
		.ignoringFields("id")
		.isEqualTo(UserTest.JAVAJIGI);
}

@Test
@DisplayName("유저를 저장한다.")
void save2() {
	final User actualUser = userRepository.save(UserTest.SANJIGI);

	assertThat(actualUser).usingRecursiveComparison()
		.ignoringFields("id")
		.isEqualTo(UserTest.SANJIGI);
}

사용자를 저장하는 2개의 테스트를 작성하였다.

단순히 사용자를 저장하는 테스트임에도, 첫 번째 메서드의 테스트에서는 아래와 같이 오류가 발생하였다.

오류 상황을 보면, User 엔티티의 createdAt, updatedAt의 값이 채워져 있지 않아 발생한 것을 볼 수 있다.
save()를 진행하게 되면 영속성 컨텍스트의 관리에 의해서 UserTest의 JAVAJIGI 변수와 actualUser가 같은 객체를 바라보고 있어서 auditing에 의해 User 엔티티의 값이 업데이트가 되면 JAVAJIGI 변수의 값도 업데이트가 될 줄 알았는데 그렇지 않았던 것이다.

 

---

 

🌱 JPA Auditing의 동작 원리 살펴보기

처음에는 Auditing에 대해 문제라고 생각이 들어서, 디버깅을 통해 언제 값이 채워지는지 살펴보기로 했다.

먼저, Auditing 시 동작하는 AuditingEntityListener 클래스의 touchForCreate() 메서드를 확인해보자.

위 메서드에서 인자로 target 값에 JAVAJIGI가 들어온 것을 볼 수 있다.

아직 auditing이 동작하지 않았기 때문에 createdAt, updatedAt 모두 null 값으로 채워진 것을 볼 수 있다.

 

object.markCreated() 메서드로 타고 들어가보자.

첫 번째 라인에서 target의 값으로 JAVAJIGI가 들어와서 어떠한 Wrapper 객체를 생성한 것을 볼 수 있다.

그리고, 날짜에 대한 auditing을 위해 touchDate() 메서드로 제어를 이동해서 살펴보자.

코드를 보면 touchAuditor를 통해 auditor에 대한 정보가 필요하면 채워넣게 되며 (@CreatedBy 같은 어노테이션을 사용할 때 동작하는 듯하다.) 우리 코드에서는 필요가 없기 때문에 바로 touchDate() 메서드로 한 번 이동해보자.

 

첫 번째 라인에서 현재 시간을 가져온 다음, wrapper::setCreatedDate, wrapper::setLastModifiedDate를 통해서 JAVAJIGI의 값을 채워넣는 것을 볼 수 있다!

실제로, target인 JAVAJIGI에 시간 관련 필드가 채워져 있는 것을 확인할 수 있었다.

 

---

🌱 JPA의 save는 어떻게 동작할까?

그렇다면 정말 이상하다. auditing까지 정상적으로 동작했음에도 불구하고 왜 createdAt, updatedAt이 null이었던 것일까?

이를 알아보기 위해서 JPA의 save() 메서드를 한 번 눈여겨 볼 필요가 있다.

기본적으로 userRepository.save() 메서드가 호출되면, isNew()라는 어떠한 메서드를 통해 새로운 객체인지 판단한다.

만약 새로운 객체라면 persist 후 기존의 엔티티를 반환하고, 그렇지 않으면 merge 후 "새로운 객체를 반환" 한다는 것이다.

여기서 힌트를 얻었다. 혹시 새로운 객체를 반환하면서 null로 된 것이 아닐까?

그래서, 새로운 객체를 판단하는 기준을 살펴보았다.

기본적으로 id (@Id 어노테이션이 붙어있는 필드)가 primitive 타입이 아니라면 null 여부를 통해 새로운 객체임을 판단하고,

primitive 타입 중 Number 타입이라면 값이 0L인지 체크하여 새로운 객체인지를 판단하게 된다.

@Entity
@EntityListeners(AuditingEntityListener.class)
public class User {

    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
}

우리가 설계했던 엔티티는 어땠을까?

User 엔티티의 아이디는 Long이고, ReferenceType이기 때문에 null이 아닌 1L을 가지게 되면 isNew() 메서드에서 false를 반환하게 된다. 그렇기 때문에, DB에 데이터가 존재하든 말든 persist가 아닌 merge() 를 진행하게 된 것이었다!

 

실제로, em.merge() 메서드를 타고 들어가다 보면 아래와 같이 MergeEventListener에 대한 이벤트가 발생하는 것을 볼 수 있다.

여기서 MergeEventListener::onMerge 메서드를 타고 들어가다 보면, entityState 라는 변수에 ‘DETACHED’라는 값이 들어간다.
우리는 이전에 JAVAJIGI 엔티티를 저장하거나 하지 않았음에도 id를 지정했기 때문에 분리된 상태라고 판단하게 된 것이다.

그리고, entityIsDetached() 메서드를 또 타고 들어가면 위와 같은 부분을 만날 수 있다.

Transient한 상태의 엔티티를 저장하는 것처럼 보이는데, 내부적으로 파고 들어가보자.

그러면 위와 같이 callbackRegistry.preCreate() 라는 메서드를 호출하는 것을 볼 수 있다.

 

해당 메서드를 내부적으로 타고 들어가다 보면, 등록된 콜백 메서드에 대해서 순회하며 하나씩 콜백 메서드를 실행한다.

이때, 인자로 넘겨주는 bean의 경우 createdAt, updatedAt이 채워지지 않은 상태의 JAVAJIGI 객체 정보이다.

여기서 callback을 확인해보면 User 엔티티에서 설정했던 AuditingEntityListener가 실행된 것을 볼 수 있다.

또한, 콜백타입 역시 PRE_PERSIST로 설정이 되어 있는데, 이건 무엇을 뜻하는 것일까?

바로, 위에서 봤던 JPA Auditing 기능에서 존재했던 touchForUpdate() 메서드 위에 달려있던 어노테이션이었던 것이다.

즉, 정리하자면 save() → em.merge() 동작 → merge 이벤트 시 JPA Auditing 동작 → 필드 채워짐 순서로 동작하게 되는 것이다.

 

---

🌱 아니, 그래서 테스트는 왜 깨진 건데요?

다시 돌아가서, em.merge()가 수행될 때 호출되는 fireMerge() 메서드를 보자.

앞서 언급했지만, JPA에서 save 시 isNew()가 false라면 em.merge()가 수행된 결과값을 save에서 반환한다.

우리의 텍스트 픽스처 JAVAJIGI의 경우 id의 타입이 레퍼런스 타입인 Long이었으며, 1L로 채워져있기 때문에 isNew()에서 false가 반환되었던 상태이다.

이 메서드에서는 event.getResult() 라는 값이 반환되는데, result에서는 createdAt, updatedAt 값이 채워진 객체가 반환된다.

하지만, 여기서 중요한 건 원본 객체 (텍스트 픽스처인 JAVAJIGI)와 반환되는 객체가 아예 다른 객체라는 것이다.

original의 경우 User@8627이었으나, result의 경우 User@8631으로, 아예 다른 객체를 반환하고 있는 것을 볼 수 있다.

 

@Test
@DisplayName("유저를 저장한다.")
void save1() {
	final User actualUser = userRepository.save(UserTest.JAVAJIGI);

	assertThat(actualUser).usingRecursiveComparison()
		.ignoringFields("id")
		.isEqualTo(UserTest.JAVAJIGI);
}

우리의 테스트 코드에서는 save로 반환된 객체와 JAVAJIGI가 아예 다른 객체가 된 것이고, save로 인해 기존의 JAVAJIGI 엔티티의 값을 변경할 것이라는 예상과 다르게 '값이 채워진 상태의 새로운 객체를 만들어 반환'했기 때문에 오류가 발생한 것이다.

즉, JAVAJIGI의 createdAt, updatedAt은 그대로 null이고, auditing은 새로운 객체에서 진행하게 되어 값이 채워져 반환된 것이다.

 

@Test
@DisplayName("유저를 저장한다.")
void save1() {
	final User actualUser = userRepository.save(UserTest.JAVAJIGI);

	assertThat(entityManager.contains(UserTest.JAVAJIGI))
		.isFalse();

	assertThat(entityManager.contains(actualUser))
		.isTrue();
}

또한, 기존의 JAVAJIGI 객체는 영속성 컨텍스트에서 관리되지 않고 merge 이후 새롭게 반환받은 객체가 영속성 컨텍스트에서 관리되는 것을 확인할 수 있다.

 

---

 

🌱 그렇다면, save2()에서는 어떻게 동작했을까?

save2()에서 사용된 SANJIGI의 경우 id가 지정되지 않아 처음 save() 시 merge가 아닌 persist() 메서드가 호출된다.

em.persist() 메서드를 타고 들어가다 보면 아래와 같이 persist에 대한 이벤트가 발생하는 것을 확인할 수 있다.
여기서 메서드의 차이도 있는데, fireMerge()의 경우 event의 result 값을 반환했었지만 여기서는 메서드의 반환값이 void인 것을 볼 수 있다. 즉, 새로운 객체를 생성하는 것이 아닌 기존의 객체를 관리한다는 것을 추론할 수 있다.

PersistEventListener::onPersist를 타고 들어가다 보면 아래와 같이 entityState가 ‘TRANSIENT’ 상태인 것을 볼 수 있다.
이는 entityManager에 의해 관리되지 않는 순수한 상태를 의미한다.

위 메서드에서 entityIsTransient() 메서드를 타고 들어가다 보면, 위와 같은 상황을 만날 수 있다.

여기서 인자로 넘기는 entity에 대한 정보는 우리가 넘긴 SANJIGI 객체인 것이다!

saveWithGeneratedId()의 이후의 과정은 save1()의 예제에서 봤던 동작 원리랑 똑같다. 

다만, createdAt, updatedAt에 대한 값이 실제 SANJIGI 객체에서 채워진다는 것이 큰 특징이다.

cf. 위에서 다루지 않은 것 같아 말하지만 Id 값 역시 이 메서드에서 채워진다!
어떤 제너레이터를 사용하는지에 따라 달라진다. (IdentifierGenerator 활용)

 

실제로 save 전후의 값을 살펴보면 동일한 엔티티에 대해서 (User@8547) 값이 채워져서 들어가는 것을 확인할 수 있다.

 

@Test
@DisplayName("유저를 저장한다.")
void save2() {
	final User actualUser = userRepository.save(UserTest.SANJIGI);

	assertThat(entityManager.contains(UserTest.SANJIGI))
		.isTrue();
	assertThat(entityManager.contains(actualUser))
		.isTrue();
}

 

또한,  save2()에서는 save 이후 SANJIGI와 actualUser 모두 영속성 컨텍스트에서 관리하는 것이 특징이다.

 

---

 

🌱 em.merge() 시에 반환받은 엔티티만 사용하자

@Test
@DisplayName("유저를 저장한다.")
void save1_duplicated_save() {
	final User actualUser1 = userRepository.save(UserTest.JAVAJIGI);
	final User actualUser2 = userRepository.save(UserTest.JAVAJIGI);

	assertThat(actualUser1).usingRecursiveComparison()
		.ignoringFields("id", "createdAt", "updatedAt")
		.isEqualTo(UserTest.JAVAJIGI);

	assertThat(actualUser2).usingRecursiveComparison()
		.ignoringFields("id")
		.isEqualTo(UserTest.JAVAJIGI);
}

 

save1() 메서드에서 한 번 더 객체를 저장했을 때의 실험이다.
actualUser1의 경우 JAVAJIGI와 actualUser1이 다르게 관리되었기 때문에 두 값이 달랐었다. (createdAt, updatedAt이 채워짐)
하지만, 한 번 더 저장한 actualUser2의 경우 JAVAJIGI와 동일하게 createdAt, updatedAt이 null이 된다. 왜 그러는 것일까?

 

먼저, actualUser1의 형태는 위와 같이 createdAt, updatedAt이 채워져 있는 형태이다.

actualUser1이 저장되는 시점의 merge() 로직을 다시 한 번 보자.
첫 번째 save() 로직에서는 MergeEventListener::onMerge 메서드에서 (merge 이벤트 발생할 때) 내부를 따라가다보면 영속성 컨텍스트에서 동일한 키값으로 관리되는 엔티티가 있는지 확인한다. 처음 save()를 할 때는 저장된 엔티티가 없기 때문에 없다고 나온다.

 

또한, entityState가 null이었지만, getEntityState를 통해 DETACHED인 상태라고 판단하게 된다.

 

그리고, 처음 봤을 때처럼 entityState가 DETACHED여서 entityIsDetached() 메서드를 타게 된다.

하지만, 영속성 컨텍스트 내부에는 id = 1이면서 entityName이 User인 객체가 존재하지 않아 result 값이 null이 되어, 

DETACHED 상태임에도 실제로는 영속화가 필요한 객체라고 판단하여 영속화를 진행하게 된다.

 

하지만, 두 번째 save() 시에는 로직이 달라진다.

em.merge()를 진행하게 되면 인자로 넘겨준 객체가 아닌, 반환받은 객체를 영속성 컨텍스트에서 관리한다고 하였다.

그렇기 때문에 첫 번째 save() 시에 반환된 actualUser1만 영속성 컨텍스트에서 관리하고, JAVAJIGI는 영속성 컨텍스트에서 관리하지 않게 된다. 하지만, 두 번째 save 시 id 값이 이미 1L로 채워진 객체가 인자로 들어왔고, 영속성 컨텍스트에는 id = 1L인 actualUser가 관리되고 있기 때문에 entry 값이 null이 아니게 된다.

 

실제로 entry 값이 위와 같이 createdAt, updatedAt이 채워진 actualUser1 객체임을 확인할 수 있다.

이후, entityState가 DETACHED여서 entityIsDetached() 메서드를 타게 된다.

 

내부를 보면 첫 번째 save와 다르게 id=1, entityName이 User인 actualUser1가 관리되고 있어 result가 존재하게 된다.

그래서 else 구문에 있는 새로운 로직이 실행되는 것을 볼 수 있다.

 

MergeContext.put()의 경우, 첫 번째 인자로 병합할 엔티티를, 두 번째 인자로 이미 관리되고 있는 엔티티를 받아서 병합한다.

실제 호출부를 보면 병합할 엔티티로 기존의 JAVAJIGI 객체가, 이미 관리되고 있는 엔티티로 영속성 컨텍스트에 의해 관리되던 actualUser1 값이 들어가는 것을 볼 수 있다.

 

이후 copyValues를 통해 JAVAJIGI 객체에 대한 정보를 바탕으로 actualUser1의 객체의 정보에 복사가 진행된다.

이로 인해 JAVAJIGI가 가진 createdAt, updatedAt의 null 값이 전파된 것이다!

 

최종적으로 결과를 세팅해주는 부분을 보면 null로 업데이트 되어서 result를 세팅해주는 것을 코드로 볼 수 있다.

그래서, actualUser2의 createdAt, updatedAt 값이 null이 되어서 JAVAJIGI랑 같은 값을 가지게 되는 것이다.

 

---

🌱 결론

- em.merge()는 파라미터로 넘어온 엔티티의 '식별자 값'으로 영속성 컨텍스트를 조회하고, 찾는 엔티티가 없으면 데이터베이스에서 조회한다.
- 만약 데이터베이스에서도 발견하지 못하면 새로운 엔티티를 생성하여 병합한다.
- 병합은 준영속 상태와 비영속 상태를 신경쓰지 않기 때문에, 식별자 값으로 엔티티를 조회할 수 있으면 조회하여 병합하고, 조회할 수 없으면 새로 생성하여 병합한다.
- 따라서 병합은 save or update 기능을 수행한다.
- em.merge를 사용할 때는 반환받은 객체만 영속성 컨텍스트에서 관리한다는 점을 유의하자!

 

옛날에 진행했던 트러블 슈팅이었는데 다시 정리하니까 새롭다.

JPA는 알다가도 정말 모르겠다 ㅎㅎ 🥲