llm-wiki/raw/company-tech-blogs/thorben-janssen-hibernate-timestamp-clock-limitation.md

title, source_type, url, archive_url, related_branches, related_projects, tags, created

title	source_type	url	archive_url	related_branches	related_projects	tags	created
Thorben Janssen — How to Persist Creation and Update Timestamps with Hibernate	company-tech-blog	https://thorben-janssen.com/persist-creation-update-timestamps-hibernate/		feature-persistence-auditing-contract		company-tech-blog ca-tmpl persistence hibernate auditing clock-injection	2026-06-10

Thorben Janssen — How to Persist Creation and Update Timestamps with Hibernate

Layer: raw/ — 외부 자료(전문가 기술 블로그)의 원문 발췌·출처 기록. 검증된 요약은 /ingest 후 wiki/concepts/에 별도 작성. 원본은 raw에 영구 보관.

Parent / 활용 branch (필수, 최소 1개+)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-persistence-auditing-contract	Hibernate-native @CreationTimestamp/@UpdateTimestamp 대안을 거부하는 근거: (a) Clock 주입 불가 → 결정론적 테스트 제약 위반, (b) created_by/updated_by 추적 불가 → 완전한 감사 로그 미지원

출처 / Source

• 원본 URL: https://thorben-janssen.com/persist-creation-update-timestamps-hibernate/
• 아카이브 URL: (미등록 — 추가 권장)
• 저자 / 조직: Thorben Janssen (thorben-janssen.com — Hibernate/JPA 전문가 기술 블로그)
• 발행일: (상세 날짜 미확인, 페이지 본문에서 연도 미표기)
• 마지막 확인일: 2026-06-10

왜 저장했는지 / Why archived

feature-persistence-auditing-contract 브랜치에서 @CreationTimestamp/@UpdateTimestamp 대안을 평가할 때, "Hibernate가 JVM 시스템 시간을 직접 읽으므로 Clock 빈 주입이 불가하다"는 제한과 "타임스탬프만 저장하는 단순 기능이라 실제 감사 솔루션이 아니다"는 저자의 직접적 진술이 두 거부 이유 모두를 뒷받침한다.

핵심 인용 / Key quotes (verbatim, Self-Grep 통과)

[§ Clock parameterization caveat] "Unfortunately, you can't parameterize it. Hibernate uses the JVM to get the current time."

[§ Audit scope disclaimer] "it only persists the timestamps so it's not a real audit solution. But if you don't need to persist any additional information (who changed what), this is the easiest solution I know."

[§ @CreationTimestamp mechanics] "When a new entity gets persisted, Hibernate gets the current timestamp from the VM and sets it as the value of the attribute annotated with @CreationTimestamp."

[§ @UpdateTimestamp mechanics] "The value of the attribute annotated with @UpdateTimestamp gets changed in a similar way with every SQL Update statement."

Claims Extracted / 추출된 주장

이 자료가 직접 말하는 것만 claim 으로 분리한다. 내 프로젝트에 적용한 결론은 여기 쓰지 않는다.

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
C1	@CreationTimestamp/@UpdateTimestamp는 Clock 파라미터화가 불가하며, Hibernate가 JVM에서 직접 현재 시간을 읽는다	"Unfortunately, you can't parameterize it. Hibernate uses the JVM to get the current time."	engineering-blog	Hibernate ORM 사용 환경 전반	특정 Hibernate 버전에 국한되는지 여부 미확인; 공식 Hibernate 문서로 보강 필요
C2	@CreationTimestamp/@UpdateTimestamp는 타임스탬프만 저장하므로 실제 감사 솔루션이 아니며, "누가 무엇을 변경했는지" 추가 정보가 없는 경우에만 적합하다	"it only persists the timestamps so it's not a real audit solution. But if you don't need to persist any additional information (who changed what), this is the easiest solution I know."	engineering-blog	감사(audit) 요건이 있는 모든 프로젝트	created_by/updated_by 컬럼 유무가 아니라 저장소 모델 결정에 대한 근거는 아님
C3	@CreationTimestamp는 엔티티가 최초 영속화될 때 VM의 현재 타임스탬프를 해당 필드에 설정한다	"When a new entity gets persisted, Hibernate gets the current timestamp from the VM and sets it as the value of the attribute annotated with @CreationTimestamp."	engineering-blog	Hibernate ORM @CreationTimestamp 사용 시	VM 시간 소스(NTP 정합 등) 정확도 보장 여부는 이 자료 범위 밖
C4	@UpdateTimestamp는 모든 SQL UPDATE 실행 시마다 값이 변경된다	"The value of the attribute annotated with @UpdateTimestamp gets changed in a similar way with every SQL Update statement."	engineering-blog	Hibernate ORM @UpdateTimestamp 사용 시	UPDATE 없이 dirty-check가 발생하는 케이스 처리 방식 미언급

Strength 허용값 (적용됨)

• engineering-blog — 개인/팀 블로그의 엔지니어링 해설. 이 자료는 Thorben Janssen의 전문가 기술 블로그로 engineering-blog 로 분류. 공식 Hibernate 문서(official-vendor-doc)가 아니므로 공식 best practice로 단독 인용 금지.

Usage Boundaries / 적용 경계

• 이 자료가 직접 증명하는 것:
  • C1: Hibernate @CreationTimestamp/@UpdateTimestamp가 Clock 주입을 지원하지 않으며 JVM 시스템 시간을 직접 사용한다는 사실 (저자 직접 진술)
  • C2: 이 애노테이션들이 "누가" 변경했는지를 기록하지 않으므로 완전한 감사 솔루션이 아니라는 저자의 명시적 평가
  • C3: @CreationTimestamp 가 최초 INSERT 시점에 VM 타임스탬프를 설정한다는 메커니즘
  • C4: @UpdateTimestamp 가 매 UPDATE마다 갱신된다는 메커니즘
• 이 자료가 증명하지 않는 것:
  • Hibernate 공식 문서(official-vendor-doc)로서의 권위: 전문가 블로그이므로 공식 사양이 아님. Clock 주입 불가 사실을 공식 확인하려면 Hibernate 공식 문서 보강 필요.
  • 어떤 감사 대안(Spring Data Auditing, Hibernate Envers 등)이 더 낫다는 비교 우위 — 이 글은 대안 평가가 아닌 사용법 설명
  • created_by/updated_by 컬럼을 어떻게 구현해야 하는지 구체적 방법
• 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  • Hibernate 공식 문서 또는 소스코드에서 C1 (JVM 시간 직접 읽기, Clock 주입 불가) 확인 — engineering-blog 단독으로는 결정 근거로 약함
  • ca-tmpl 의 실제 Hibernate 버전에서 동일하게 적용되는지 검증

메모 / Notes

• C1 은 결정론적 테스트를 위해 Clock 빈을 주입하는 이 프로젝트의 테스트 전략과 직접 충돌한다. @CreationTimestamp/@UpdateTimestamp 를 사용하면 테스트에서 시간을 제어할 수 없어 시간 의존 로직의 단위 테스트가 불가능해진다.
• C2 는 이 프로젝트가 created_by/updated_by 컬럼을 요구하는 경우 이 대안을 아예 배제하는 독립적인 거부 이유가 된다.
• 이 자료는 전문가 기술 블로그이므로 engineering-blog Strength 로 처리. 공식 사양을 보강하려면 Hibernate 공식 문서(@CreationTimestamp/@UpdateTimestamp Javadoc 또는 User Guide)를 별도 official-doc 으로 등록 권장.
• 추가로 봐야 할 동일 출처 페이지: Thorben Janssen의 Hibernate Envers 관련 글 (완전한 감사 대안으로 비교 가능)

Related / 관련

• 같은 주제 다른 official-doc / company-tech-blog: Hibernate 공식 User Guide의 @CreationTimestamp/@UpdateTimestamp 항목 (아직 미등록)
• 이 자료를 인용한 wiki 요약: [[wiki/concepts/hibernate-timestamp-auditing]] (생성 시)