DongHyeonkaandClaude Fable 5.1
b25357c48a
- analysis/·source-index·state.json 을 final/document.md 제2부·제3부로 접었다. SSOT 는 하나다 - 파일럿 — commit-ambiguity-as-a-result 를 새 기준으로 재선별. 후보 14 → 글감 5 (PROMOTE 5 · MERGE_INTO 3 · KEEP_IN_SSOT 4 · 보류 2). 기록 5건을 다시 썼고 그림 1개를 techviz 로 만들었다 - 재선별이 잡은 것: 제1부 §6.2·§11.1 이 자기 §13.2 와 어긋나 있었다(레인을 안 돌렸다 vs 돌렸다) — 정정. 이미 답이 나와 있던 Question 을 HEAD 재실행 질문으로 다시 세웠다. Concept 이 인용한 코드가 SSOT 에 없어 뺐다 - candidateScope·sourceRepository 기록. 나머지 43개 주제는 재선별 대기(PENDING 905) Co-Authored-By: Claude Fable 5.1 <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을 모두 감당할 수 있는지 확인한다.