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.8 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, assets, evidence, source, module
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | evidenceCapturedOn | assets | evidence | source | module | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CONCEPT | adapter-outbound-persistence-jpa-c13 | 이미 소비한 시간을 트랜잭션 계층이 다시 주지 않는다 | state-machines-and-ownership | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | concept:adapter-outbound-persistence-jpa-c13 | 2026-09-01 |
|
|
|
adapter-outbound-persistence-jpa |
이미 소비한 시간을 트랜잭션 계층이 다시 주지 않는다
application policy path는 timeout을 TransactionDefinition.setTimeout() 하나로 끝내지 않는다. CallBudget admission이 connection pool을 빌리기 전부터 시작한다.
본문
application policy path는 timeout을 단순히 TransactionDefinition.setTimeout() 하나로 끝내지 않는다. ca-skeleton.jpa.transaction settings는 transaction/resource-budget defaults를 가진다.
- duration positive
- duration <= 1 day
- retry max attempts 1..5
- statement timeout <= transaction timeout
- lock timeout < statement timeout
- completion/acquisition/action margin hierarchy
즉 runtime에서 무한 retry나 무한 transaction timeout을 property 하나로 열 수 없게 hard cap을 둔다.
RetryProfile 참조 위치
:::evidence key="adapter-outbound-persistence-jpa-c13" alt="코드베이스에서 RetryProfile 를 검색한 출력 14줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="RetryProfile 코드베이스 검색 — 14줄 · exit 0" zoom="true" :::
이 점은 API RetryProfile.maxAttempts가 upper bound를 갖지 않는 것과 대비된다. canonical application path는 실제 deployment settings에서 최대 5회를 강제한다.
풀에서 기다린 시간이 다시 주어지지 않는다
CallBudget admission은 connection pool을 빌리기 전부터 시작한다. transaction을 열 가치가 있으려면 남은 budget이 최소한을 감당해야 하고, begin 후에는 실제 남은 budget으로 Spring whole-transaction timeout, statement timeout, lock timeout, idle-in-transaction timeout을 정한다. 따라서 pool에서 오래 기다린 요청이 "원래 5초 timeout이었으니 DB에서 다시 5초"를 받지 않는다.
backoff도 budget을 본다
canonical path의 retry backoff도 CallBudget-aware다. 다음 attempt를 시작하기 전에 jitter delay, 다음 acquisition reserve, 다음 최소 transaction/action margin을 모두 감당할 수 있는지 확인한다.