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>
3.0 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-c26 | 쓰기 경로마다 트랜잭션 소유가 다르다 | transaction-and-consistency-models | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | concept:adapter-outbound-persistence-jpa-c26 | 2026-09-01 |
|
|
|
adapter-outbound-persistence-jpa |
쓰기 경로마다 트랜잭션 소유가 다르다
HibernateBulkDmlExecutor는 arbitrary JPQL을 아무 데서나 실행하는 helper가 아니고, HibernateStatelessSessionRunner는 이 platform에서 transaction ownership 예외를 명시적으로 드러낸다.
본문
HibernateBulkDmlExecutor는 arbitrary JPQL string을 아무 데서나 실행하는 helper가 아니다. operation name 등록, affected-row expectation, persistence-context cleanup, transaction requirement를 contract로 둔다. bulk DML은 managed entity lifecycle을 우회하므로 ordinary entity save와 같은 audit/lifecycle guarantee를 기대하면 안 된다.
쓰기 경로마다 다른 소유 모델
:::evidence key="adapter-outbound-persistence-jpa-c26-diagram" alt="쓰기 경로에서 일반 repository adapter 와 bulk DML 과 StatelessSession runner 로 화살표가 나가고 화살표마다 트랜잭션 소유 방식이 붙은 구조" caption="쓰기 경로마다 다른 소유 모델" zoom="false" :::
HibernateBulkDmlExecutor 참조 위치
:::evidence key="adapter-outbound-persistence-jpa-c26" alt="코드베이스에서 HibernateBulkDmlExecutor 를 검색한 출력 7줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="HibernateBulkDmlExecutor 코드베이스 검색 — 7줄 · exit 0" zoom="true" :::
사용 중이라고 주장하지 않는 이유
support matrix도 이를 Advanced capability로 분리한다. 현재 production business consumer는 확인되지 않았고 PostgreSQL integration fixture에서 실제 behavior를 qualification한다. 따라서 "runtime에서 사용 중"이라고 주장하지 않는다.
이름만 row cap 이던 문제는 고쳐져 있다
HibernateStatelessSessionRunner는 오히려 이 platform에서 transaction ownership 예외를 명시적으로 드러낸다 — 일반 repository adapter는 application transaction boundary에 참여하고, StatelessSession runner는 그렇지 않다. 과거 review에서는 caller가 선언한 maxRows가 실제 affected rows와 연결되지 않는 문제가 있었다. 현재는 StatelessWorkResult(value, affectedRows)를 요구하고 cap 초과 시 commit 전에 rollback한다.