document-haness/docs/clean-architecture-backend-template/tech-log-studio/owner-safe-state-machines/reference/reference-read-the-clock-after-the-lock.md

kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, verifiedOn

kind	slug	title	topic	project	status	sourceRevision	rootTreeNode	verifiedOn
REFERENCE	read-the-clock-after-the-lock	시간은 DB에서, 그리고 행을 잠근 다음에 읽는다	owner-safe-state-machines	clean-architecture-backend-template	게시 전	21234e38cdb9a926cbc92bb97a2aee2e4a7d2916	reference:read-the-clock-after-the-lock

시간은 DB에서, 그리고 행을 잠근 다음에 읽는다

애플리케이션 시계로 리스 만료를 판단하거나 lock wait 이전의 시각으로 판단해 서로 다른 노드가 같은 행에 대해 다른 답을 내는 것을 막는다. 이 규칙에서는 행 lock을 획득한 뒤 PostgreSQL clock_timestamp()를 읽는다. transaction 시작 시각인 now()·CURRENT_TIMESTAMP·transaction_timestamp()는 lock wait 이후의 실제 시각을 반영하지 않으므로 이 용도의 대체재로 쓰지 않는다.

목적

애플리케이션 시계로 리스 만료를 판단하거나 잠그기 전의 시각으로 판단해, 서로 다른 노드가 같은 행에 대해 다른 답을 내는 것을 막는다.

규칙

1. 행 lock 뒤 clock_timestamp()를 읽는다 여러 노드의 애플리케이션 시계 대신 DB 시계를 쓰고, lock wait가 끝난 뒤 호출 시점의 실제 시각을 읽는다. now()와 CURRENT_TIMESTAMP는 transaction start time이라 이 용도에는 맞지 않는다.

2. lock 이전에 읽은 시각을 재사용하지 않는다 잠금을 기다리는 동안 lease가 만료될 수 있으므로 판정에 쓰는 시각은 lock 획득 후 다시 얻는다.

3. 판정과 갱신을 한 문장 안에 둔다 시각 비교를 where 절에 넣으면 판정과 갱신 사이에 시간이 흐르지 않는다.

4. 만료 시각을 계산할 때도 같은 시계를 쓴다 읽은 시각과 쓰는 시각의 출처가 다르면 리스 길이가 의도와 달라진다.

적용 조건

리스와 청구와 예약처럼 시각이 소유권을 정하는 모든 상태 기계

여러 인스턴스가 같은 테이블을 폴링하는 구조

예외

단일 인스턴스만 접근하고 그 보장이 구조적인 경우는 애플리케이션 시계로 충분하다. 그 보장을 적어 둔다.

예시

청구 결정 트리가 데이터베이스에서 읽은 현재 시각으로 리스 만료를 판정한다.

리스를 발행 타임아웃보다 길게 두는 것은 확률을 낮출 뿐이고, GC 정지나 스케줄러 지연을 데이터 제약으로 바꾸지 않는다.

관계

• CAS 튜플을 where 절에 전부 반복하고 update count를 답으로 쓴다 같은 문장 안에서 함께 쓰이는 규칙이다.
• fenced lease — 만료 시각만으로는 부족한 이유 시각만으로 부족한 이유를 다룬 개념이다.