---
kind: REFERENCE
slug: write-transactions-need-a-finite-timeout
title: 쓰기 트랜잭션에는 유한 타임아웃이 필수다
topic: transaction-deadline-and-pool
project: clean-architecture-backend-template
status: 게시 전
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
rootTreeNode: reference:write-transactions-need-a-finite-timeout
verifiedOn:            # 이 기록은 이번 회차에 실행 확인을 하지 않았다
---

# 쓰기 트랜잭션에는 유한 타임아웃이 필수다

## 목적

타임아웃 없는 쓰기 트랜잭션이 잠금을 무한히 들고 있어, 다른 쓰기 전부를 막는 것을 방지한다.

## 규칙

1. 쓰기 경로에 무한 대기를 두지 않는다
   타임아웃이 없으면 잠금 대기가 끝나지 않는다.

2. 기본값을 무한으로 두지 않는다
   설정하지 않았을 때의 동작이 무한 대기면, 설정을 잊은 배포가 가장 위험한 배포가 된다.

3. 읽기와 쓰기의 상한을 따로 둔다
   읽기가 길어지는 것과 쓰기가 길어지는 것은 영향 범위가 다르다.

4. 타임아웃 값을 타입으로 강제한다
   설정 값이 비어 있을 수 있는 형태면 그 경로가 언젠가 무한이 된다.

## 적용 조건

잠금을 잡는 모든 쓰기 트랜잭션

여러 인스턴스가 같은 행을 경합하는 구조

## 예외

관리자가 명시적으로 실행하는 일회성 마이그레이션이나 백필은 상한이 다를 수 있다. 그 경우 실행 절차에 그 사실이 있어야 한다.

## 예시

트랜잭션 템플릿이 모드마다 미리 만들어져 있고 전부 같은 격리 수준에 고정되어 있다. 데드라인은 실행 시점에 계산되어 전달된다.

풀 커넥션 타임아웃은 기본 30 초 대신 짧은 값으로 고정한다. 풀이 고갈된 스레드를 오래 붙잡지 않고 빠르게 거절하기 위해서다.

## 관계

- **데드라인은 호출 예산에서 시작해 세 단계로 좁힌다**
  이 규칙이 속한 전파 구조다.
- **커밋 모호성 판정은 넓혀도 좁혀도 해롭다**
  타임아웃이 만드는 실패를 어떻게 분류할지 다룬 규칙이다.