공부하는 개발자 핑구

`@Volatile` 이해하기

DevPing9_ — Wed, 31 Dec 2025 16:05:09 +0900

@Volatile
private var something: Something

동료분이 해당 코드에 리뷰를 해주었다.

@Volatile 은 ThreadLocal 에 저장하는 키워드로 알고 있는데, Webflux + 코루틴 환경에서 문제가 없을까요?

@Volatile 은 CPU 캐시가 아닌 메인 메모리를 보게하는 명령어라고만 알고 있었다.
문제가 없어보이지만 혹시 내가 아는게 다르지 않을까 싶어 여러 문서를 뒤져보고 알게 된 지식을 정리하고자 한다.

# Volatile

CPU 캐시는 ThreadLocal(JVM Heap 에 저장되는 자료구조) 에 저장되는 값이 아닌 OS 의 CPU Core 에 저장되는 캐시이다.
@Volatile 키워드는 메모리 모델 상의 happens-before 관계만 정의한다. 즉, JVM 이 어떻게 이를 구현할지는 자유이다.
이때 말하는 메모리는 Java Thread 의 ThreadLocal 이 아닌 JMM 을 뜻한다.
@Volatile 에 관해 CPU 캐시가 아닌 메인 메모리를 보게한다는 설명은 교육적 예시일 뿐이다.
- Volatile 설명 Highlight Link
- OrcleDocs

결론적으로 @Volatile 은 JMM 규칙(visibility/ordering 를 보장)이며, JVM이 이를 지키기 위해 메모리 장벽 같은 기법으로 보장한다. 어떤 방식으로 보장할 것인지는 제한하지 않고 있다. 실제 캐시/메모리 동작은 JVM 구현과 CPU 아키텍처에 의존한다.

# Volatile 이 보장하는 것

1. visibility

한 스레드가 값을 쓰면 다른 스레드가 항상 최신 값을 보게 한다.

2. ordering

이전의 모든 쓰기가 이후의 모든 읽기보다 먼저 보임

# @Volatile vs ThreadLocal

구분	@Volatile	ThreadLocal
공유 여부	공유됨	스레드별
가시성	보장	의미 없음
스레드 이동	안전	깨짐
WebFlux	사용 가능	위험

gRPC Unary 와 REST API 속도 차이 (1) - 직렬화, 역직렬화

DevPing9_ — Thu, 17 Jul 2025 10:13:54 +0900

직렬화 포맷 (Protocol Buffers vs JSON)

조금만 검색해보아도 gRPC 는 데이터 직렬화를 바이너리로 하니 더 빠르다는 정보를 찾을 수 있다.
JSON 도 직렬화하면 바이너리로 변환되는데 무슨 차이점이 있을까?

그래서, 정확히 어떤 방식으로 데이터가 직렬화 되기에 페이로드가 짧아지는지 알아보자.

JSON 직렬화

JSON 문자열을 바이너리로 바꾼다는 건, 해당 문자열을 UTF-8 바이트 시퀀스로 변환하는 것을 말한다.

{
  "name": "Alice",
  "age": 30
}

위 데이터를 바이트 시퀀스(16진수)로 직렬화하면

7b 22 6e 61 6d 65 22 3a 22 41 6c 69 63 65 22 2c 22 61 67 65 22 3a 33 30 7d

총 25 bytes

JSON 문자열	바이트
{	7b
"name":	22 6e 61 6d 65 22 3a
"Alice"	22 41 6c 69 63 65 22
,	2c
"age":	22 61 67 65 22 3a
30	33 30
}	7d

Protobuf 직렬화

미리 정의된 스키마를 기반으로 필드 번호와 타입, 값만 이진 규격에 맞게 바이트 시퀀스로 변환한다.

message Person {
  string name = 1;
  int32 age = 2;
}

위 데이터를 바이트 시퀀스(16진수)로 직렬화하면

0a 05 41 6c 69 63 65 10 1e

총 9 bytes

Protobuf 직렬화	바이트
field 1 (name), wire type 2	0a
문자열 길이 5	05
'A' 'l' 'i' 'c' 'e' (ASCII)	41 6c 69 63 65
field 2 (age), wire type 0	10
숫자 30 (varint 인코딩)	1e

직렬화 비교

JSON 문자열	바이트	Protobuf 직렬화	바이트
{	7b
"name":	22 6e 61 6d 65 22 3a	field 1 (name), wire type 2	0a
"Alice"	22 41 6c 69 63 65 22	'A' 'l' 'i' 'c' 'e' (ASCII)	41 6c 69 63 65
,	2c
"age":	22 61 67 65 22 3a	field 2 (age), wire type 0	10
30	33 30	숫자 30 (varint 인코딩)	1e
}	7d

[Network] DHCP 에 대해 정말 간략히 알아보자

DevPing9_ — Sun, 26 Jan 2025 19:35:08 +0900

DHCP(Dynamic Host Configuration Protocol)

네트워크에 연결된 장치(클라이언트)에게 자동으로 IP 주소, 서브넷 마스크, 게이트웨이, DNS 서버 등 네트워크 설정 정보를 할당하는 프로토콜

과거에는 IP를 고정적으로 수동할당하였다. IP 충돌이나 고갈을 해결하기 위하여 나온 자동할당 프로토콜이다.

DHCP 서버

DHCP 서버는 주로 라우터에 위치한다. 경우에 따라 전용 DHCP 서버를 개설하여 관리할 수 있다.

[Network] ARP 와 RARP (MAC 주소가 필요한 이유)

DevPing9_ — Sun, 26 Jan 2025 19:28:27 +0900

들어가기 전에

	IP 주소	MAC 주소
정의	네트워크 상에서 논리적 식별자	하드웨어 네트워크 인터페이스의 물리적 주소
OSI 계층	3계층 (네트워크 계층) 패킷 전달을 위해 사용	2계층 (데이터 링크 계층) 프레임 전송을 위해 사용
목적	전 세계, 인터넷 통신	로컬 네트워크 내부 통신
변경 여부	네트워크에 따라 변경 가능	기본적으로 변경 불가능 (제조 시 할당)
할당 방식	정적 또는 동적 (DHCP)	하드웨어에서 자동 할당
역할	장치의 논리적 위치 식별	로컬 네트워크 내 데이터 전송 식별

개요

	ARP 와 RARP	NDP
정의	IP 주소와 MAC 주소(장치의 물리적 주소)를 상호 변환하는 데 사용되는 프로토콜
사용범위	IPv4 네트워크	IPv6 네트워크

IP 로만 데이터를 전송할 수는 없나? MAC 주소를 왜 꼭 알아야하는가?

대부분의 네트워크 장치는 OSI 2계층에서 동작하며, 2계층의 PDU 인 프레임을 전송하기 위하여 MAC 주소가 필요하다.

* 스위치, WAP, NIC, 브릿지, 라우터등의 네트워크장치는 보통 1~3계층까지만 구현이 되어있다.

호스트 A 에서 호스트 B 로 데이터를 전송한다고 가정하자.

호스트 A 는 여러 네트워크 장치를 거쳐 최종적으로 호스트 B에게 1계층 비트신호로 데이터를 전달하게 될 것이고, 호스트 B 는 1계층 비트신호를 7계층까지 Decapsulation 하여 A가 보내고자 했던 애플리케이션 데이터(7계층)을 추출한다.

비트신호(1계층)를 프레임(2계층)으로 변환할 때 MAC 주소가 필요하고, 프레임(2계층)을 패킷(3계층)으로 변환할 때 IP 주소가 필요하기 때문에 MAC 주소가 꼭 필요한 것이다.

ARP(Address Resolution Protocol)

정의:
- IP 주소를 MAC 주소로 변환하는데 사용되는 프로토콜
동작과정:
1. 호스트 A가 특정 IP 주소에 데이터를 보내려면 해당 IP의 MAC 주소를 알아야 함
2. 호스트 A는 네트워크 전체에 ARP 요청(브로드캐스트) 패킷을 보냄.
3. 해당 IP를 가진 호스트 B가 자신의 MAC 주소를 포함한 ARP 응답(유니캐스트) 패킷을 전송.
4. 호스트 A는 응답을 받고, IP-MAC 매핑 정보를 ARP 캐시(테이블)에 저장하여 이후에는 동일 요청을 반복하지 않음.
종류:
- 일반 ARP:
  - 특정 IP의 MAC 주소를 찾기 위한 표준 ARP
- GARP (Gratuitous ARP):
  - 중복 IP 감지 또는 ARP 캐시 갱신을 위해 자신의 정보를 네트워크에 알리는 방식
- 프록시 ARP: (시스코 Docs)
  - 라우터가 다른 네트워크를 대신하여 응답 (라우터 설정에 있음)
공격 사례
- ARP 스푸핑 공격
  - 공격자가 가짜 MAC 주소로 응답하여 중간자 공격 수행

RARP (Reverse Address Resolution Protocol)

정의:
- MAC 주소를 IP 주소로 변환하는데 사용되는 프로토콜
- 자신의 IP를 알지 못할 경우 사용됨
동작과정:
1. 클라이언트는 자신의 MAC 주소만 알고 있으며 IP 주소를 알지 못함.
2. 클라이언트는 네트워크에 RARP 요청(브로드캐스트)을 보냄.
3. 네트워크의 RARP 서버가 요청을 수신하고, 클라이언트 MAC 주소와 일치하는 IP를 데이터베이스에서 조회.
4. 서버는 클라이언트에게 해당 MAC 주소에 대한 IP 주소를 응답(유니캐스트)으로 제공.
단점 및 대체기술
- RARP는 구성이 복잡하고, IP 주소 할당을 위한 별도의 RARP 서버가 필요
- 현재는 DHCP (Dynamic Host Configuration Protocol)가 RARP를 대체

[Network] 전달한 패킷이 네트워크 장치가 수용할 수 있는 크기보다 크다면? (MTU, MSS, PMTUD)

DevPing9_ — Sat, 18 Jan 2025 20:23:37 +0900

들어가기전에

OSI 7 Layer 의 2계층인 Data Link Layer 에서는 Ethernet 프로토콜을 사용한다.

네트워크 장치들이 모두 OSI 7계층 모델을 사용하는 것은 아니지만, 네트워크 통신을 수행하는 장치들은 OSI 모델의 계층 중 일부를 사용하거나 참고한다.

LAN(Local Area Network)을 구성하기 위해 네트워크 카드(NIC), 스위치, 라우터, 허브, 액세스 포인트 등과 같은 네트워크 장치가 사용되는데, 이러한 네트워크 장치를 통하여 데이터가 전달된다.

우리는 전송할 데이터를 쪼개어 전송하게 되는데 쪼개어진 데이터를 *패킷이라고 칭하며, 일반적으로 패킷의 크기가 클수록 대역폭(Bandwidth)을 효과적으로 사용할 수 있다.

난 효율적인게 좋아!

우리집 인터넷은 1Gbps 라구!

굳이 데이터를 잘라서 보내서 오버헤드를 만들지 말고 한방에 보내버리면 완전 빠르겠구만!

컴퓨터에서 내보낸 패킷은 1GB지만, 다른 노드까지 향하는 길목에는 여러 네트워크 장치들이 있다.

해당 네트워크 장치들이 어느정도 크기의 데이터를 한번에 받을 수 있는지도 중요하다.

* 보통 대부분의 네트워크 장치들은 1500 바이트를 받을 수 있도록 만들어져 있다.

네트워크 장치가 데이터 링크 계층(OSI 2계층)에서 허용하는 최대 페이로드 크기를 *MTU 라고 하며, 네트워크 경로 상에 있는 아무 장치나 MTU 보다 패킷이 크면 그 패킷은 분할될 수도 있다.

IPv6 은 분할을 허용하지 않으며, IPv4 는 헤더의 플래그 값에 따라 분할여부가 결정된다.

IPv4 의 패킷분할 여부를 결정하는 Flags 헤더

어쩔 수 없네.. 1500바이트로 보내야겠다.

직접 1500 바이트로 데이터를 보내게되면 패킷이 도달하지 못하는 것을 확인할 수 있다.

이유는 필자가 사용한 bash 는 사용자를 위한 Application 이며, 때문에 ping 의 -s 옵션인 데이터의 크기는 보통 유저입장에서는 헤더를 포함하지 않은 순수한 payload 의 데이터 크기로 인식되기 때문이다.

이를 설명하기 위한 개념이 MTU(Maximum Transmission Unit) 와 MSS(Maximum Segment Size) 이다.

MTU 와 PDU

누군가는 MTU 를 네트워크 계층 트랜잭션 에서 통신할 수 있는 가장 큰 프로토콜 데이터 단위 (PDU)의 크기라고 정의하기도 한다. (나무위키 참조)

사실 앞서 설명한 MTU 의 정의인 데이터 링크 계층(OSI 2계층)에서 허용하는 최대 페이로드 크기가 시초의 정의라고 필자는 생각하지만, 중요한건 증명이 아니라 PDU 가 무엇을 설명하고 싶어서 나온 용어인가이다.

헤더나 부가정보를 제외한 순수 데이터의 크기를 측정하고 공유하고 싶기에 해당 용어가 생겨났다고 본다.

앞서 OSI 7 Layer 의 2계층인 Data Link Layer 에서는 Ethernet 프로토콜을 사용한다고 설명하였다.

또한, 3계층인 Network Layer 에서는 IP 프로토콜을 사용한다.

MTU 와 MSS

Ethernet 프로토콜의 PDU 인 프레임의 구성

위 이미지는 Ethernet 프로토콜의 PDU 인 프레임의 구성을 보여주고 있으며 검색을 하면 흔하게 접할 수 있는 이미지이다.

MTU 는 참조정보(헤더,FCS)가 아닌 순수 데이터를 측정하기 위해 태어난 단위라고 앞서 설명하였다.

그래서 Ethernet MTU 는 Ethernet 프로토콜의 참조정보를 제외한 크기를 나타내지만, IP MTU 는 이상하게도 IP 헤더를 포함한 크기로 측정한다.

MTU 의 정의가 데이터 링크 계층(OSI 2계층)에서 허용하는 최대 페이로드 크기가 정의의 시초였다고 생각하는 이유가 바로 IP MTU 때문이다.

MSS(Maximum Segment Size)는 용어에서 보이듯 세그먼트를 사용하는 4계층의 PDU의 관한 용어이다.

Maximum Segment Size 라는 영문을 보면 알 수 있듯이 MTU 와 같은 뜻을 담고 있지만 계층을 구분하고 싶어 생겨난 단어라는 것을 짐작할 수 있다.

즉, MSS 의 정의는 Transport 계층(OSI 4계층)에서 허용하는 최대 페이로드 크기이다.

때문에 Ethernet MTU 와 동일하게 4계층까지의 부가정보(헤더 등)를 제외한 데이터의 크기를 나타낸다.

그래서 사용자가 사용하는 Application 에서는 MTU 가 1500 인 서버에 데이터를 보내고 싶다면, 헤더 값을 고려하여 1500 보다 작게 보내야 한다.

참고로 ping의 경우 IP 헤더(20바이트) + ICMP 헤더(8바이트)로 요청을 보내는 것이기 때문에 MSS는 1472 까지 가능하다.

데이터를 보낼 때 항상 실험을 해야된다면 너무 비효율적인 것 같은데..

그렇다. 내 주변 LAN 의 구성이야 사용자가 노력해서 알 수 있다고 하지만, 데이터를 보낼 서버의 LAN 은 사용자가 어떻게 매번 조사를 하겠는가. 애초에 도착지점까지의 모든 장치의 MTU 를 미리 알 수 있다하더라도, 유지보수 이후 MTU 가 변경된다면 무슨소용인가.

이를 해결하기 위한 기술이 PMTUD(Path MTU Discovery) 이며 경로 MTU를 동적으로 탐색하여 데이터를 분할하지 않고 최적 크기의 패킷으로 전송되도록 조정하는 역할을 수행한다.

PMTUD 간략 개요

하지만 대충 봐도 알 수 있듯이 초기 MTU 탐색 과정에 비용이 발생하고, 경로상에 있는 네트워크 장치들은 응답값에 ICMP 메시지를 작성하고 그 안에 MTU 를 넣어 반환하게 되는데 보안상의 이유로 ICMP 메시지를 차단하는 네트워크가 있을 수도 있다.

이에 대해 자세히 설명하게 되면 포스팅이 길어지기에 여기에서 마친다.

패킷의 크기에 대하여

오해가 있을까봐 첨언합니다.

패킷의 크기가 크면 당연히 slice 과정과 merge 과정의 오버헤드는 물론 헤더의 중복에 대한 오버헤드도 줄일 수 있다는 장점등이 있다.

반대로 작다면 손실된 패킷에 대한 재전송에 대한 부담이 적어진다는 점과 혼잡한 네트워크 속에서 대역폭을 나눠쓰기 때문에 네트워크 혼잡을 완화할 수 있다는 장점등이 있다.

	패킷이 커요!	패킷이 작아요!
장점	1. 헤더 오버헤드 감소 2. CPU 부하 감소 3. 전송 속도 감소	1. 패킷 손실 시 재전송 부담 감소 2. 네트워크 혼잡 완화 3. 네트워크 경로상의 Fragmentation 방지 4. 지연 시간 감소 5. 오류 확산 방지 6. 일부 프로토콜에서 헤더 압축 효율성 증가
적합한 환경	고속 데이터 전송과 효율성이 중요한 곳 ex) 데이터 센터 네트워크, 고속 전송 네트워크, 클라우드 및 파일 서비스, VPN/터널링 환경	호환성 문제, 네트워크 안정성 및 경로 MTU 탐색비용 감소 ex) 인터넷 연결이 불안정한 지역, 무선 네트워크, 실시간 애플리케이션, 혼잡한 네트워크, VPN/터널링 환경

MTU (Maximum Transmission Unit)

정의:
네트워크에서 데이터 링크 계층(OSI 2계층)에서 허용하는 최대 페이로드 크기

MSS (Maximum Segment Size)

정의:
네트워크에서 전송 계층(OSI 4계층)에서 허용하는 최대 페이로드 크기

[Network] 노드와 네트워크 장치, 링크와 회선

DevPing9_ — Fri, 17 Jan 2025 17:53:08 +0900

1. 노드 (Node)

정의:
- 데이터를 생성하거나 소비하는 장치
예시:
- 클라이언트 노드: 컴퓨터, 스마트폰, IoT 기기 등
- 서버 노드: 웹 서버, 데이터베이스 서버
- 기타 노드: 네트워크 프린터, NAS(Network Attached Storage), IoT 센서
특징:
- 일반적으로 데이터의 생성 또는 최종 소비를 담당
- 사용자가 직접 상호작용하는 장치가 많음

2. 네트워크 장비 (Network Device)

정의:
- 노드 간의 데이터 흐름을 관리하고 최적화하는 데 사용되는 장치
- 자체적으로 데이터를 생성하거나 소비하지는 않지만, 데이터를 전달하거나 처리하는 데 중요한 역할을 수행
예시:
- 스위치(Switch): LAN(Local Area Network)에서 데이터를 전달
- 라우터(Router): 서로 다른 네트워크 간 데이터 전송을 관리
- 허브(Hub): 데이터를 단순히 모든 연결된 장치로 브로드캐스트
- 방화벽(Firewall): 네트워크 보안을 관리
- 액세스 포인트(AP): 무선 네트워크에 장치를 연결
- LAN 카드 : 노드 내부에 설치되어 노드를 네트워크에 연결
특징:
- 네트워크의 물리적 및 논리적 연결을 관리
- 트래픽 최적화, 보안, 네트워크 제어와 같은 기능 제공

3. 링크(Link)

정의:
- 데이터가 이동할 수 있는 물리적 또는 논리적 연결 통로
- 노드와 네트워크 장치를 물리적/논리적으로 연결
예시:
- 이더넷 케이블, 광케이블, Wi-Fi 신호, 블루투스 연결, 위성 통신 링크, VPN

4. 회선(Circut)

정의:
- 링크 위에 설정되는 특정 사용자나 목적을 위한 전용 통신 경로
예시:
- 두 지점을 연결하는 광케이블 링크 위에 전용 회선을 설정
- ATM 네트워크의 가상 회선, 전화 회선, 전용 임대 회선

* ATM 네트워크 : 데이터를 고정된 크기의 셀(Cell)로 분할하여 전송하는 네트워크 통신 기술

# 요약 비교

	노드(Node)	네트워크 장치(Network Device)	링크(Link)	회선(Circut)
역할	데이터의 생성, 소비, 처리	데이터의 전달 및 네트워크 최적화	데이터의 이동 통로	링크 위에 설정되는 특정 사용자나 목적을 위한 전용 통신 경로
예시	PC, 스마트폰, 서버, IoT 장치	스위치, 라우터, 방화벽, 허브	이더넷 케이블, 광케이블, Wi-Fi 신호, 블루투스 연결, 위성 통신 링크, VPN	ATM 네트워크 가상 회선, 전화 회선, 전용 임대 회선

[Spring] 트랜잭션에 대한 실험과 고찰 (Self-invocation, 프록시가 메서드를 실행하기까지의 과정)

DevPing9_ — Sun, 1 Dec 2024 21:36:27 +0900

[Spring] 예외 발생시 Spring DB 트랜잭션 롤백 안되는 경우

배경지식Checked Exception 은 개발자가 인지한 예외라 약속한다.Unchecked Exception 은 개발자가 인지하지 못한 예외라 약속한다.try-catch 문에서 catch 된 Exception 은 개발자가 인지한 예외라 약속한다.스프

developer-ping9.tistory.com

Spring DB 트랜잭션의 롤백 유무에 대해 정리하다가 프록시 객체가 언제 생성되는지, 어떤 원리로 만들어지는지 고찰을 하기 위해 여러 실험을 진행해보았다. 다른 블로그 글을 읽어도 이해가 잘안되고, 블로그마다 말이 좀 다른게 있어 쉽게 믿을 수가 없었다.

무엇보다 제일 궁금했던 점은 프록시가 나의 서비스클래스를 상속받아서 만들어지는지, 아니면 주입받아서 사용하는지의 여부였다.

경제적인 관점에서 주입받아서 사용하는 편이 비용적으로 저렴하니까 당연하다 생각하였는데, 다른 블로그 포스팅에서 상속받아서 만들어낸다는 글도 있어서 무시할 수가 없었다.

검증 전 필자가 생각한 이상적인 프록시 객체의 코드

@Class
class ProxyService(
	private val myUserService: MyUserService,
): Proxy {
	fun registerUser(...) {
    	Proxy.preProcess()
        myUserService.registerUser(...)
        Proxy.postProcess()
    }
}

요롷게 안되어있으면 컨트리뷰트 해봐야지!!! +_+

아래 내용들은 스프링 라이브러리 코드를 기반으로 디버깅하여 모두 확인 검증하였으니 안전하게(?) 받아들여도 된다.

검증 방법 따라해보기

1. CglibAopProxy (프록시 생성 과정 및 원객체 메서드 실행 디버깅 가능)

2. TransactionInterceptor (트랜잭션 인터셉터 실행과정 디버깅 가능)

3. logging.level.org.springframework.transaction.interceptor: TRACE
(트랜잭션 열리고 닫히는 과정을 로깅을 통해 관찰가능)

4. TransactionInterceptor.invoke() -> CglibAopProxy.proceed() 의 this.target 의 주소값과 서비스 메서드가 실행될때의 서비스 주소값을 비교

@Transactional 어노테이션으로 인해 생성된 프록시가 메서드를 실행하기 까지의 과정

// <When Application Initialized>
1. Parsing the Annotation
2. Proxy Creation

// <When Proxy(service) method called>
3. Transaction Advice Execution
4. Method Execution (해당 메서드는 프록시 객체가 아닌 서비스 객체의 메서드이다.)
5. Transaction Commit

여기서 주목할 점은 4. Method Excution 이 프록시 객체가 아닌 스프링빈의 메서드라는 점이다.

즉, 프록시는 우리가 작성한 서비스를 상속하여 생성되는 것이 아니라 주입 받아서 생성되는 것이다.

이 점을 검증하기 위해서 정말 고생을 많이했다...

스프링빈의 메서드라는 점 하나로 많은게 당연시 된다.

1. private 메서드에는 @Transactional 을 붙여도 동작하지 않는다.
2. Self-invocation 시, 하위 메서드들에 붙은 @Transcational 은 무시된다.
3. Self-invocation 시, 하위 메서드들은 상위 메서드의 트랜잭션에 종속된다.

따라서 상위 메서드의 트랜잭션과 하위 메서드의 트랜잭션을 분리하여 처리하고 싶다면, 하위 메서드가 프록시객체에서 호출되어야 한다.

이를 실현하기 위해 아래의 방법을 사용할 수 있다.

1. 하위 메서드와 상위 메서드의 클래스를 분리시킨다.
2. 순환참조로 자기자신을 주입받은 후, 순환참조된 객체에서 하위메서드를 호출한다. (권장하지 않습니다)

2번은 권장하지 않는데, 단일책임의 원칙으로 설계된 클래스의 트랜잭션이 서로 분리되어 처리되어야 할 일은 거의 없을 것이기 때문이다.

따라서 2번의 경우가 발생한다면 클래스의 책임분리가 잘되어있는지 고민해야하는 시점이라고 생각한다.

+ 트랜잭션 롤백유무에 관한 실험과 결과

Self-invocation

상위 메서드 @Transactional	상위 메서드 예외	하위 메서드 @Transactional	하위 메서드 예외	롤백유무 (상위 / 하위)
O	X	O	O(Runtime)	O / O
O	X	O(rollbackFor)	O(Checked)	X / X
O(rollbackFor)	X	O or X	O(Checked)	O / O
O	O(Runtime)	O(requires_new)	X	O / O

Non-self-invocation

상위 메서드 @Transactional	상위 메서드 예외	하위 메서드 @Transactional	하위 메서드 예외	롤백유무 (상위 / 하위)
O	X	O	O(Runtime)	O / O
O	X	O(rollbackFor)	O(Checked)	O / O
O(rollbackFor)	X	O or X	O(Checked)	O / O
O	O(Runtime)	O(requires_new)	X	O / X
O	X	O(requires_new)	O(Runtime)	O / O
O	X	O(requires_new, rollbackFor)	O(Checked)	X / O

+ 컨트리뷰트 할 거리 없나 싶어 추가로 실험/검증한 사실

1. @Transactional 어노테이션을 가지지 않은 서비스빈들은 프록시 객체로 생성되지 않고 스프링빈으로 생성 됨.
2. @Transactional 어노테이션이 없더라도, 순환참조로 자기자신을 참조할 경우 프록시 객체가 생성 됨.
3. 트랜잭션이 분리가 되더라도 Runtime Exception 이 상위 메서드에 전파가 되고 상위 메서드에서 따로 핸들링하지 않는다면 상위 메서드의 트랜잭션도 롤백된다.

스프링에 컨트리뷰트 해보고 싶었는데 역시 이미 잘 만들어져있다 ㅎㅎㅎ... 쳇...

[Spring] 예외 발생시 Spring DB 트랜잭션 롤백 안되는 경우

DevPing9_ — Wed, 27 Nov 2024 18:44:15 +0900

배경지식

Checked Exception 은 개발자가 인지한 예외라 약속한다.
Unchecked Exception 은 개발자가 인지하지 못한 예외라 약속한다.
try-catch 문에서 catch 된 Exception 은 개발자가 인지한 예외라 약속한다.
스프링은 개발자가 인지한 예외에 대해서는 기본적으로 롤백을 진행하지 않는다.
예외가 발생한 메서드의 Propagation 레벨이 Required(default) 가 아니면 부모트랜잭션은 롤백되지 않는다.
프록시가 Self invocation 을 시도할 경우 경우에 따라 트랜잭션이 롤백되지 않을 수 있다.

[Spring] 트랜잭션에 대한 실험과 고찰 (Self-invocation, 프록시가 메서드를 실행하기까지의 과정)

[Spring] 예외 발생시 Spring DB 트랜잭션 롤백 안되는 경우배경지식Checked Exception 은 개발자가 인지한 예외라 약속한다.Unchecked Exception 은 개발자가 인지하지 못한 예외라 약속한다.try-catch 문에서 catc

developer-ping9.tistory.com

발생 케이스

발생한 예외가 Checked Exception
- @Transational 어노테이션에 rollbackFor 을 설정하지 않은 경우
발생한 예외가 Unchecked Exception
- try-catch 구문안에서 핸들링되는 경우 (Unchecked Exception 을 왜 잡으려고 하는거에요?)
- @Transational 어노테이션에 noRollbackFor 가 설정된 경우
자식 메서드의 Propagation 레벨이 Required 가 아닐 경우
프록시의 Self invocation 으로 인한 경우

Reference

Rolling Back a Declarative Transaction :: Spring Framework

You must carefully consider how specific a pattern is and whether to include package information (which isn’t mandatory). For example, "Exception" will match nearly anything and will probably hide other rules. "java.lang.Exception" would be correct if "E

docs.spring.io

응? 이게 왜 롤백되는거지? | 우아한형제들 기술블로그

이 글은 얼마 전 에러로그 하나에 대한 호기심과 의문으로 시작해서 스프링의 트랜잭션 내에서 예외가 어떻게 처리되는지를 이해하기 위해 삽질을 해본 경험을 토대로 쓰여졌습니다. 스프링의

techblog.woowahan.com

[이슈 #1] Spring Transaction의 Self Invocation 이슈

Spring Transaction의 Self Invocation 이슈 문제 인식 Spring Security를 이용한 OAuth 로그인 기능을 구현하기 위해 커스텀한 OAuth2UserService를 개발하던 중, 영속 상태에 있는 인스턴스의 필드 변경 사항이 DB에

yejun-the-developer.tistory.com

[트러블슈팅] You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near (~~~)

DevPing9_ — Wed, 27 Nov 2024 18:14:40 +0900

원인

DB 예약어를 컬럼명으로 사용하여 JPA가 SQL 문을 제대로 작성하지 못함

해결

컬렴명 이스케이프

@Column(name="\"left\"")

[MySQL] DB에 이상한 데이터가 있어요! (MySQL Strict mode)

DevPing9_ — Mon, 2 Oct 2023 18:02:04 +0900

발단

데이터 중에 누가봐도 이상한게 있었다.

테스트 데이터겠지, 그 때 어플리케이션 코드가 이상했겠지로는 설명이 안되는 최신데이터로 말이다.

MySQL Strict Mode

MySQL 5.7 이상 버전들은 Strict Mode 가 기본설정이지만, 그 이하 버전들은 Strict Mode 가 꺼져있다.

Strict Mode 가 꺼져있다면 에러가 나야 할 쿼리들이 에러 없이 실행된다.

varchar(4) 로 설정했지만 10글자의 String 을 INSERT 문으로 작성하여도 성공적으로 실행된다.

아래 포스팅에 잘 설명되어 있으니 참고하자.

MySQL Strict mode 끄기/켜기

MySQL 5.7 부터는 STRICT_MODE 가 기본 설정이라고 하니 별도의 설정 작업이 필요없다.

www.lesstif.com

그럼 Strict Mode 를 키면 되나?

이미 Strict Mode 가 꺼진채로 운영중인 시스템에서 켜 버린다면 재앙이 발생할 수 있다.

누군가는 Strict Mode 가 꺼진 것을 인지하고 어플리케이션 코드를 짜버렸을 수도 있으니까 말이다.

이럴 때에 변경 비용이 적은게 바로 마이크로서비스 아키텍처이구나... 라고 열심히 느끼고 있다.

어플리케이션에서 값 검증

이런 상황에서는 DB 를 믿지 못하니 insert 할 객체에 validation 을 모조리 걸어버리는 방법밖에는 없다.

DB 가 할 일을 어플리케이션에서 중복으로 하는 느낌이 들어 매우 거부감이 들었다.

Strict Mode 가 켜져있다면, 어플리케이션에서는 값에 대한 검증을 미뤄도 될까?

동료들과 토의 결과, 답은 '아니다' 로 귀결 되었다.

어플리케이션에서 값에 대한 검증을 하지 않는다면, Client 는 SQL Error Message 를 보게 된다.

비지니스에 대한 에러메세지가 아닌 그저 특정 값을 insert/update 할 수 없다라는 메세지만 받기 때문에 작업자는 비지니스에 대한 요구사항을 정확히 알 수 없다.

오래된 작업일수록 히스토리를 알기 어려워지는데, 그 때 에러메세지라도 비지니스적으로 작성이 되어있다면 히스토리 파악에 도움이 되기에 유지보수비용을 줄일 수 있다 라는 것이 결론이다.