DongHyeonkaandClaude Opus 5
b2963105a8
The keycloak project ended with four open questions that design could not
settle. A two-VM lab was built to answer them by measurement, and this is
that material: 26 experiments, 125 raw command outputs, 22 browser captures.
Follows the import procedure in README.md.
source/ the originating repository verbatim — 78 documents, 28 SVGs,
8 manifests, plus .source-revision recording the commit
final/ the SSOT
document.md 729 lines written from the 29 experiment documents, not
concatenated: what was predicted, what was measured, and
where the measurement itself was wrong
evidence/raw 125 outputs, flattened to <experiment>__<file> because
the originals collided (01-baseline.txt appeared three
times) and the audit only globs the top level
evidence/meta one per raw file; command and exitCode are null and the
README says why rather than inventing them
evidence/browser 22 captures
assets/ three diagrams through techviz
.techviz/ their VizSpecs
A separate project rather than an addition to keycloak: the B-layer answers
that project's four questions, but the A, C and D layers are about cluster
failure, SSO and operations, and one document.md should hold one subject.
The four question records there can point here through 관계.
Recorded rather than papered over: only three of the 28 diagrams were
remade. The repository forbids hand-drawn SVG and forbids titles inside the
canvas; all 28 originals carry both, so converting them is redrawing, not
reformatting. They stay in source/ and the gap is written into the document.
verify-pipeline.py passes. audit-records.py reports no issues.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
56 lines
2.1 KiB
Markdown
56 lines
2.1 KiB
Markdown
---
|
|
kind: REFERENCE
|
|
slug: write-transactions-need-a-finite-timeout
|
|
title: 쓰기 트랜잭션에는 유한 타임아웃이 필수다
|
|
topic: transaction-deadline-and-pool
|
|
project: clean-architecture-backend-template
|
|
status: 게시 전
|
|
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
|
rootTreeNode: reference:write-transactions-need-a-finite-timeout
|
|
verifiedOn: # 이 기록은 이번 회차에 실행 확인을 하지 않았다
|
|
---
|
|
|
|
# 쓰기 트랜잭션에는 유한 타임아웃이 필수다
|
|
|
|
## 목적
|
|
|
|
타임아웃 없는 쓰기 트랜잭션이 잠금을 무한히 들고 있어, 다른 쓰기 전부를 막는 것을 방지한다.
|
|
|
|
## 규칙
|
|
|
|
1. 쓰기 경로에 무한 대기를 두지 않는다
|
|
타임아웃이 없으면 잠금 대기가 끝나지 않는다.
|
|
|
|
2. 기본값을 무한으로 두지 않는다
|
|
설정하지 않았을 때의 동작이 무한 대기면, 설정을 잊은 배포가 가장 위험한 배포가 된다.
|
|
|
|
3. 읽기와 쓰기의 상한을 따로 둔다
|
|
읽기가 길어지는 것과 쓰기가 길어지는 것은 영향 범위가 다르다.
|
|
|
|
4. 타임아웃 값을 타입으로 강제한다
|
|
설정 값이 비어 있을 수 있는 형태면 그 경로가 언젠가 무한이 된다.
|
|
|
|
## 적용 조건
|
|
|
|
잠금을 잡는 모든 쓰기 트랜잭션
|
|
|
|
여러 인스턴스가 같은 행을 경합하는 구조
|
|
|
|
## 예외
|
|
|
|
관리자가 명시적으로 실행하는 일회성 마이그레이션이나 백필은 상한이 다를 수 있다. 그 경우 실행 절차에 그 사실이 있어야 한다.
|
|
|
|
## 예시
|
|
|
|
트랜잭션 템플릿이 모드마다 미리 만들어져 있고 전부 같은 격리 수준에 고정되어 있다. 데드라인은 실행 시점에 계산되어 전달된다.
|
|
|
|
풀 커넥션 타임아웃은 기본 30 초 대신 짧은 값으로 고정한다. 풀이 고갈된 스레드를 오래 붙잡지 않고 빠르게 거절하기 위해서다.
|
|
|
|
## 관계
|
|
|
|
- **데드라인은 호출 예산에서 시작해 세 단계로 좁힌다**
|
|
이 규칙이 속한 전파 구조다.
|
|
- **커밋 모호성 판정은 넓혀도 좁혀도 해롭다**
|
|
타임아웃이 만드는 실패를 어떻게 분류할지 다룬 규칙이다.
|
|
|