최범균님 유튜브 초식 트랜잭션 강의 메모

1. 트랜잭션이란?
2. 트랜잭션이 없다면?
3. 트랜잭션 범위는 커넥션 기준 -> 커넥션 하나 생성후 중간에 메소드를 호출하여 다른 커넥션을 생성한다면 롤백할때 같이 롤백되지않음 -> 트랜잭션 전파 -> 보통 프레임워크가 이 기능을 제공한다 (@Transactional)
4. 트랜잭션과 외부 연동 -> 트랜잭션 내에 외부연동이있는데 외부연동 실패했으면 내부디비는 롤백이되겠지만 외부연동된건 어떻게 처리할건지 (2PC (two-phase commit) 글로벌트랜잭션 -> 거의사용하지 않음) 이벤트/비동기 메시징
5. 트랜잭션은 원자성 -> all or nothing
6. 트랜잭션의 범위는 중요하다 문제가 발생했을때 롤백해야하는 범위 -> 격리

7. 같은데이터에 동시접근하는 상황 (당직 예시: 최소한명은 담당자인데 A,B 사람이 동시에 자신을 담당자에서 빼는 쿼리 -> 당직자 0명 문제)
8. 여러클라이언트가 같은 데이터에 접근하는 문제를 경쟁 상태(Race Condition)
9. 이런문제를 해결하기위해 트랜잭션 격리(Isolation) -> 트랜잭션을 서로 격리해서 다른 트랜잭션이 영향을 주지 못하게 함
10. 가장 쉬운방법은 트랜잭션을 순서대로 실행하면 된다 -> 동시성 문제 아예없음
11. 근데 왜 이방법을 사용하지 않냐? -> 성능(처리량)이 저하된다. 게다가 트랜잭션하나가 어떤 이유로 계속 대기 상태이거나 처리하는데에 시간이 매우길어진다면 줄줄이 다른 트랜잭션이 모두 영향받음. 대용량 트래픽이라면 이경우에 어떻게 될까?
12. 그래서 다양한 격리 수준을 지원한다 -> Read Uncommittied, Read committed, Repeatable Read, Serializable
13. 동시성 관련 다양한 문제들 -> 커밋되지 않은 데이터 읽기, 커밋되지 않은 데이터 덮어쓰기, 읽는 동안 데이터 변경 1, 변경 유실, 읽는동안 데이터 변경 2
14. Dirty Read, Dirty Write 를 발생하지 않도록 하기위해 디비는 Read Committed라는 격리수준을 제공한다. -> 커밋된 데이터만 읽는다 - 커밋된 값과 트랜잭션 진행중인 값을 따로 보관, 커밋된 데이터만 덮어쓴다 -> 행단위 잠금 사용 -> 같은 데이터를 수정한 트랜잭션이 끝날때까지 대기 (그럼 이게 트랜잭션을 순서대로 사용하는거랑 다른점이 뭐지?)

15. 읽는동안 데이터 변경1 -> 한명이 셀렉하는동안 다른 사람이 업데이트해서 결과 셀렉이 달라지는 상황
16. 이 문제를 방지하기 위해 Repeatable Read 격리수준을 지원한다. 트랜잭션을 진행하는동안

Repeatable Read 부터 다시 보기 -> 10분정도 부터