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>
2.1 KiB
2.1 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, decisionStatus, decidedOn, source
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | decisionStatus | decidedOn | source | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PROJECT_DECISION | templates-are-built-once-per-mode | 트랜잭션 템플릿은 모드별로 미리 만들어 둔다 | transaction-deadline-and-pool | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | decision:templates-are-built-once-per-mode | ADOPTED | 2026-08-30 |
|
트랜잭션 템플릿은 모드별로 미리 만들어 둔다
결정문
트랜잭션 템플릿을 모드마다 하나씩 미리 만들어 두고, 호출마다 템플릿의 속성을 바꾸지 않는다.
판단 이유
템플릿은 가변 객체다. 하나를 공유하면서 호출마다 전파 방식이나 타임아웃을 바꾸면 두 스레드가 서로의 설정을 본다.
그 경합은 재현이 어렵다. 대부분의 호출은 같은 값을 쓰므로 증상이 드물게 나타나고, 나타났을 때는 트랜잭션이 잘못된 전파 방식으로 실행된 결과만 남는다.
그래서 모드마다 별도 템플릿을 두고 전부 같은 격리 수준에 고정한다. 쓰기와 읽기와 새 트랜잭션 셋이다.
데드라인처럼 호출마다 달라지는 값은 템플릿의 필드가 아니라 실행 시점에 계산해 전달한다.
영향
감수하는 것
모드가 늘면 템플릿도 늘어난다. 조합이 많아지면 이 방식이 부담이 된다.
호출마다 달라져야 하는 값은 별도 경로로 전달해야 한다. 템플릿에 넣을 수 없다.
얻는 것
템플릿 경합이 구조적으로 사라진다.
각 모드가 무엇으로 설정되어 있는지 한 자리에서 보인다.
근거
- 호출 예산에서 DB 로컬 타임아웃까지의 데드라인 전파 호출마다 달라지는 값이 어떻게 전달되는지 설명한다.
- Atomic 타입의 존재는 원자성의 증거가 아니다 가변 공유 상태를 다루는 같은 계열의 규칙이다.