Files

T

DongHyeonka d71669eb59 fix: 하네스 제거 및 keycloak 문서 보강

2026-07-25 12:53:13 +09:00

8.3 KiB

Raw Blame History

title, source_type, url, archive_url, status, confidence, tags, related_branches, related_projects, created, last_reviewed

title

source_type

url

archive_url

status

confidence

spring-custom-transaction-interceptor (GitHub Reference 구현)

Layer: raw/company-tech-blogs/ — Vassilis Soum 개인 GitHub repository 의 README 와 코드 발췌. Spring TransactionInterceptor 를 확장해 Try 모나드와 통합한 reference 구현체. 검증된 요약은 /ingest 후 wiki/concepts/에 별도 작성. 원본은 raw에 영구 보관.

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-application-port-usecase-contract	functional error 타입을 유지하면서 Spring TX 를 활용하는 대안 (= ca-tmpl 의 정반대 dependency 방향) 의 reference 구현체 근거
raw/branch-notes/feature-transaction-concurrency-contract	Topic 2 — Transaction Boundary 대안 5 (Custom AOP / TransactionInterceptor 확장) 의 reference 구현체
raw/project-notes/ca-skeleton-operational-contract	§14. Transaction / Concurrency Contract — TransactionPort 결정의 dependency 방향 비교군

컨텍스트 / 왜 저장했는지

ca-tmpl 의 TransactionPort 결정에 대한 대안 5 의 레퍼런스 구현체. 함수형 에러 타입(Try/Either) 을 유지하면서 Spring 트랜잭션 관리 인프라를 재사용하기 위해 TransactionInterceptor 를 직접 확장한 코드.

출처 / Source

원본 URL: https://github.com/VassilisSoum/spring-custom-transaction-interceptor
아카이브 URL: (미수집)
저자 / 조직: Vassilis Soum (개인 GitHub, 산업 예제 다수)
발행일: 2024
마지막 확인일: 2026-05-27

핵심 인용 / Key quotes (verbatim)

[§README — TransactionInterceptor 설명] "The TransactionInterceptor is a Spring AOP interceptor that intercepts all methods annotated with the @Transactional annotation."

[§README — Try 모나드 통합 동기] "In this example we use the custom TransactionInterceptor to handle transaction management for the com.soumakis.control.Try monad to be able to express exceptions as types in the method signature."

[§README — 확장 인터페이스] "The TransactionInterceptor is a custom implementation of the org.aopalliance.intercept.MethodInterceptor interface."

[§README — 핵심 동작] "It is used to intercept method invocations and execute custom logic before and after the method invocation."

[§README — 설정 요구사항] "In application.properties or application.yml allow overriding spring beans by setting spring.main.allow-bean-definition-overriding=true"

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
VSOUM-TX-C1	Spring 의 표준 `TransactionInterceptor` 는 `@Transactional` 메서드를 가로채는 AOP 인터셉터이며, 본 repo 는 그것을 확장한 custom 구현체를 제공	[§README — TransactionInterceptor 설명] "The TransactionInterceptor is a Spring AOP interceptor that intercepts all methods annotated with the `@Transactional` annotation."	`engineering-blog`	Spring AOP + `@Transactional` 환경	`@Transactional` 외 메타 어노테이션 (`@SpringTransactional` 등 custom) 처리 여부는 본 인용 범위 밖
VSOUM-TX-C2	확장 동기는 `com.soumakis.control.Try` 모나드 가 Spring TX 와 호환되도록 만들기 위함 — 예외를 메서드 시그니처의 타입으로 표현 가능	[§README — Try 모나드 통합 동기] "In this example we use the custom TransactionInterceptor to handle transaction management for the com.soumakis.control.Try monad to be able to express exceptions as types in the method signature."	`engineering-blog`	functional error handling + Spring TX	이 패턴이 모든 functional library (Vavr `Either`, kotlin-result 등) 에서 동작한다는 뜻은 아님 — `Try` 한정
VSOUM-TX-C3	custom TransactionInterceptor 는 `org.aopalliance.intercept.MethodInterceptor` 인터페이스를 구현하며, 메서드 invocation 전후 custom logic 실행 가능	[§README — 확장 인터페이스] "The TransactionInterceptor is a custom implementation of the `org.aopalliance.intercept.MethodInterceptor` interface." + "It is used to intercept method invocations and execute custom logic before and after the method invocation."	`engineering-blog`	Spring AOP / aopalliance 기반 인터셉터 확장	구현체가 모든 Spring 버전 / Boot 버전에서 호환된다는 뜻은 아님 (API 안정성 별도)
VSOUM-TX-C4	본 패턴은 `spring.main.allow-bean-definition-overriding=true` 설정을 요구 (Spring 의 기본 TransactionInterceptor bean 을 override)	[§README — 설정 요구사항] "In `application.properties` or `application.yml` allow overriding spring beans by setting `spring.main.allow-bean-definition-overriding=true`"	`engineering-blog`	Spring Boot 2.1+ (bean override 기본 비활성)	bean override 활성화의 다른 side-effect (다른 bean 충돌 디버깅 비용) 는 본 인용 범위 밖

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것:
- VSOUM-TX-C1 ~ C4: TransactionInterceptor 확장의 구조, Try 모나드 통합 동기, aopalliance 인터페이스, bean override 설정 요구사항
이 자료가 증명하지 않는 것:
- 이 패턴이 산업계 표준 / 권장 패턴이라는 주장 (engineering-blog 수준 — 개인 GitHub repo)
- prod 환경에서의 안정성 또는 성능 측정값 (README 에 수치 없음)
- Spring 마이너 버전 업그레이드 시 내부 API 변화에 대한 호환성 보장
내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl 이 functional error 타입 (Try/Either) 을 사용하는지 — 그렇지 않으면 본 패턴의 핵심 동기 (VSOUM-TX-C2) 가 부합하지 않음
- spring.main.allow-bean-definition-overriding=true 의 부수 효과가 ca-tmpl 의 다른 bean 정의와 충돌하지 않는지

메모 / Notes (내 프로젝트 해석)

본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

적용 시나리오: 이미 @Transactional 을 광범위하게 쓰는 코드베이스에 functional error 핸들링(Try/Either) 을 도입하고 싶을 때.
장점:
- 기존 Spring TX 인프라(PlatformTransactionManager, propagation) 그대로 활용.
- rollback rule 을 Either.Left / Try.Failure 같은 데이터로 표현 → throw 남용 감소.
단점:
- application 코드는 여전히 Spring annotation 에 노출.
- bean override 활성화 → 부작용 디버깅 비용.
- 라이브러리 업그레이드 시 TransactionInterceptor 내부 변화로 깨질 위험.
ca-tmpl(TransactionPort) 와의 차이: 본 repo 는 "Spring TX 를 더 강하게 활용", ca-tmpl 은 "Spring TX 를 숨김". 같은 'AOP 활용 트랜잭션' 카테고리지만 dependency 방향이 정반대.
testability 영향: 낮음 — Spring context 필수.
code 복잡도 영향: 높음.

같은 주제 다른 raw:
- raw/company-tech-blogs/hexagonal-reflectoring-transactional-placement (baseline @Transactional direct)
- raw/company-tech-blogs/transaction-port-clean-ddd-spring-medium (TransactionPort 대안)
- raw/company-tech-blogs/woowahan-hexagonal-multimodule (multi-module 보완)
인용하는 branch:
- raw/branch-notes/feature-application-port-usecase-contract
- raw/branch-notes/feature-transaction-concurrency-contract
인용하는 project:
- raw/project-notes/ca-skeleton-operational-contract (§14, §5)
인용한 wiki 요약: (미작성)
대안 그룹: Topic 2 — Transaction Boundary (대안 5종: TransactionPort / @Transactional direct / TransactionTemplate / Functional monad / Custom AOP)
본 source 의 위치: 대안 5: Custom AOP / TransactionInterceptor 확장 (functional 통합)

8.3 KiB Raw Blame History