DB Config설정과 TransactionManager 정리

스프링 부트에서 사용되는 DataSource와 TransactionManager에 대한 개념을 정리해보려고한다.

✅ 한 줄 요약

🔹 Hikari = 빠른 커넥션 푼 + 로컬 트랜잭션 전용
🔹 Atomikos = 전역(JTA/XA) 분산 트랜잭션 용
둘은 같은 DataSource처럼 보이지만, 역할이 완전히 다르다.

✅ Hikari?

1. JDBC 커넥션 풀
2. 목적 : DB커넥션을 빠르고, 적게, 효율적으로 재사용하기 위해 존재

트랜잭션 매니저 없음 ❌
분산 트랜잭션 없음 ❌
그냥 커넥션 대여소 역할만 함

✅ Hikari의 역할 정리

✅ Hikari + Spring 트랜잭션 구조

[서비스 @Transactinal]
⬇️
[DataSourceTransactionManager] ← 스프링이 커밋/롤백을 담당한다.
⬇️
[HikariDataSource] ← 커넥션만 빌려줌
⬇️
[DB]

정리?
• 커밋/롤백 주체는 스프링이다.
• Hikari는 커넥션만 제공한다.
• 트랜잭션 범위 = DB 1개( 로컬 크랜잭션)
• dataSource 빈 등록 할 떄 트랜잭션 매니저 등록도 이루어져야지 스프링 트랜잭션 매니저가 관리

✅ Hikari는 언제 쓰냐?
• 단일 DB 트랜잭션
• 일반적인 웹 서비스 90%
• MyBatis, JPA 대부분의 경우
• 분산 트랜잭션 필요 없을 때

✅ Atomikos란?

1. JTA/XA 기반 전역(분산) 트랜잭션 매니저
2. 목적 : 여러 DB, 여러 시스템을 하나의 트랜젹션처럼 묶기 위해 존재
3. 커넥션풀이 아니다.
4. 그냥 dataSource도 맞지만, 사실상 JTA 트랜잭션 참가용 리소스를 의미한다.

✅ Atomikos의 역할 정리

✅ Atomikos + Spring 트랜잭션 구조

[ 서비스 @Transactional ]
↓
[ JtaTransactionManager ] ← ✅ Spring이 Atomikos에게 위임
↓
[ AtomikosTransactionManager ]← ✅ 실제 전역 트랜잭션 매니저
↓
[ AtomikosDataSourceBean ] ← ✅ XA 리소스
↓
[ DB1 ][ DB2 ][ MQ ] ← ✅ 전부 하나의 트랜잭션

정리?
• 커밋/롤백 주체는 Atomikos다.
• 스프링은 트랜잭션 시작/종료 타이밍만 제어한다.
• 트랜잭션 범위는 여러 DB, MQ, 외부 시스템이다.

✅ Atomikos는 언제 쓰냐?

• db 두개 이상을 한번에 같이 커밋/롤백 해야할 때 사용한다.
• db + 메세지큐(kafka, rabbitMQ) 같이 묶을 때
• 금융, 정산, 결제, 회계 시스템일 경우
• MSA에서 데이터 정합성을 강하게 보장해야할 때 사용한다.

✅ 3️⃣ Hikari vs Atomikos 핵심 비교표

✅ Hikari 쓸 때
@Transactional
→ DataSourceTransactionManager
→ HikariDataSource
→ DB

✔ Spring이 commit / rollback 직접 수행
✔ autocommit은 트랜잭션 밖에서만 의미 있음
✔ 단일 DB 전용

✅ Atomikos 쓸 때
@Transactional
→ JtaTransactionManager
→ AtomikosTransactionManager
→ AtomikosDataSourceBean
→ 여러 DB / MQ

✔ 커밋 / 롤백은 Atomikos가 수행
✔ autocommit 개념은 사실상 무효
✔ 전역 트랜잭션

✅ 5️⃣ 언제 뭘 써야 하는지 “실무 기준”

✅ Hikari만 쓰면 되는 경우 (대부분)
“DB 하나만 쓰고”
“서비스 하나만 묶으면 되고”
“속도가 중요하고”
“분산 트랜잭션 필요 없음”
👉 이 경우 Atomikos 쓰면 오히려 독임

✅ Atomikos를 써야 하는 경우
✅ DB A + DB B 동시에 성공해야 함
✅ DB + MQ 같이 묶어야 함
✅ 중간 하나라도 실패하면 전부 롤백되어야 함
👉 이때만 Atomikos가 의미 있음

✅ 최종 결론
1. Hikari는 “빠른 커넥션 풀 + 로컬 트랜잭션용”
2. Atomikos는 “느리지만 강력한 전역(JTA) 분산 트랜잭션용”
3. 둘은 경쟁 관계가 아니라 완전히 다른 계층의 도구

내가 궁금해서 찾아본것은 dataSource 등록 할 때 transactionManager 등록 및 사용에 대한 것이다.

✅ Hikari든 Atomikos든,
@transactional 로 스프링이 트랜잭션을 관리하려면 반드시 PlatformTransactionManager이 필요하다.

🔹 차이점은 “누가 그 매니저를 만들어주느냐”다.
Hikari → 내가 직접 만들어줘야 하는 경우가 대부분
Atomikos → Spring Boot가 자동으로 만들어주는 경우가 대부분

그래서 정리하자면

✅ Hikari는 보통 내가 DataSourceTransactionManager를 직접 등록해야 하고,
✅ Atomikos는 Spring Boot starter를 쓰면 JtaTransactionManager가 자동 등록된다.
하지만 둘 다 결국은 PlatformTransactionManager가 있어야
@Transactional이 실제로 동작한다는 점은 완전히 동일하다.