#Step 19 — 트랜잭션과 락

START TRANSACTION;
UPDATE s19_accounts SET balance = balance - 5000 WHERE account_id = 1;
UPDATE s19_accounts SET balance = balance + 5000 WHERE account_id = 2;
COMMIT;   -- 둘 다 확정. 중간에 서버가 죽었으면 둘 다 취소됨.

START TRANSACTION;
UPDATE s19_accounts SET balance = balance - 1000 WHERE account_id = 1;
SAVEPOINT after_withdraw;
UPDATE s19_accounts SET balance = balance + 1000 WHERE account_id = 3;   -- 잘못된 대상
ROLLBACK TO SAVEPOINT after_withdraw;   -- 3번 입금만 취소, 1번 출금은 유지

-- NOWAIT : 잠긴 행을 만나면 즉시 에러 (기다리지 않음)
SELECT seat_id, seat_no FROM s19_seats WHERE seat_id = 1 FOR UPDATE NOWAIT;

-- SKIP LOCKED : 잠긴 행은 건너뛰고, 잠기지 않은 행만 가져온다
SELECT seat_id, seat_no FROM s19_seats
 WHERE status='FREE' ORDER BY seat_id LIMIT 2 FOR UPDATE SKIP LOCKED;

SELECT ENGINE_TRANSACTION_ID AS trx, OBJECT_NAME AS tbl, INDEX_NAME AS idx,
       LOCK_TYPE, LOCK_MODE, LOCK_STATUS, LOCK_DATA
FROM performance_schema.data_locks WHERE OBJECT_NAME='s19_seats';

SELECT waiting_pid, waiting_query, blocking_pid, wait_age
FROM sys.innodb_lock_waits;

-- 오래 열려 있는 트랜잭션 찾기
SELECT trx_id, trx_started,
       TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS age_sec,
       trx_rows_locked, trx_query
FROM information_schema.innodb_trx
ORDER BY trx_started;

-- 히스토리 리스트 길이(언두가 얼마나 쌓였나) — 계속 커지면 위험 신호
SHOW ENGINE INNODB STATUS\G   -- "History list length" 항목

-- =====================================================================
-- Step 19 — 트랜잭션과 락  setup.sql
-- ---------------------------------------------------------------------
-- 두 세션 실습에 쓸 전용 사본 테이블을 만듭니다.
-- 공용 테이블(accounts 같은 건 없지만 products/orders 등)은 건드리지 않습니다.
--
-- 실행:
--   mysql -h127.0.0.1 -P3307 -ulearner -plearn1234 shop < setup.sql
-- =====================================================================
USE shop;

DROP TABLE IF EXISTS s19_accounts;
CREATE TABLE s19_accounts (
  account_id INT PRIMARY KEY,
  owner      VARCHAR(30)   NOT NULL,
  balance    DECIMAL(12,2) NOT NULL,
  KEY idx_owner (owner)
) ENGINE=InnoDB COMMENT='계좌 이체/락 실습';
INSERT INTO s19_accounts VALUES
  (1,'김민수',100000),(2,'이지은',50000),(3,'박철수',30000),(4,'최영희',0);

DROP TABLE IF EXISTS s19_seats;
CREATE TABLE s19_seats (
  seat_id   INT PRIMARY KEY,
  seat_no   VARCHAR(10) NOT NULL,
  status    ENUM('FREE','BOOKED') NOT NULL DEFAULT 'FREE',
  booked_by VARCHAR(30) NULL,
  KEY idx_status (status)
) ENGINE=InnoDB COMMENT='좌석 예약(SKIP LOCKED) 실습';
INSERT INTO s19_seats VALUES
  (1,'A1','FREE',NULL),(2,'A2','FREE',NULL),(3,'A3','FREE',NULL),
  (4,'A4','FREE',NULL),(5,'A5','FREE',NULL);

SELECT 's19 setup 완료' AS msg,
       (SELECT COUNT(*) FROM s19_accounts) AS accounts,
       (SELECT COUNT(*) FROM s19_seats)    AS seats;

-- =====================================================================
-- Step 19 — 트랜잭션과 락  practice.sql  (단일 세션 개념)
-- ---------------------------------------------------------------------
-- 두 세션이 필요한 실습(격리수준/락/데드락)은 session-a.sql / session-b.sql
-- 에서 진행합니다. 이 파일은 혼자서 확인할 수 있는 기초 개념만 다룹니다.
--
-- 먼저 setup.sql 을 실행해 두세요.
--   mysql -h127.0.0.1 -P3307 -ulearner -plearn1234 shop --table < practice.sql
--
-- ★ 안전 규칙: 공용 테이블은 절대 변경하지 않습니다. s19_* 사본만 씁니다.
-- =====================================================================
USE shop;

-- ---------------------------------------------------------------------
-- [19-1] autocommit — 평소 우리는 "자동 커밋" 세계에 산다
-- ---------------------------------------------------------------------
SELECT @@autocommit AS autocommit;   -- 보통 1

-- autocommit=1 이면 UPDATE 한 방이 곧바로 커밋됩니다.
-- 명시적으로 START TRANSACTION 을 하면 그 순간부터 수동 커밋 모드가 됩니다.

-- ---------------------------------------------------------------------
-- [19-2] START TRANSACTION / COMMIT — 원자성(Atomicity)
-- ---------------------------------------------------------------------
-- 계좌 이체: 1번 → 2번 5000원. 둘 다 되거나 둘 다 안 되거나여야 한다.
START TRANSACTION;
UPDATE s19_accounts SET balance = balance - 5000 WHERE account_id = 1;
UPDATE s19_accounts SET balance = balance + 5000 WHERE account_id = 2;
SELECT '이체 후(커밋 전)' AS step, account_id, owner, balance
FROM s19_accounts WHERE account_id IN (1,2) ORDER BY account_id;
COMMIT;

SELECT '커밋 후' AS step, account_id, owner, balance
FROM s19_accounts WHERE account_id IN (1,2) ORDER BY account_id;

-- ---------------------------------------------------------------------
-- [19-3] ROLLBACK — 취소
-- ---------------------------------------------------------------------
START TRANSACTION;
UPDATE s19_accounts SET balance = 0 WHERE account_id = 1;   -- 실수!
SELECT '롤백 전(세션 안에서만 보임)' AS step, balance FROM s19_accounts WHERE account_id=1;
ROLLBACK;
SELECT '롤백 후(원래대로)' AS step, balance FROM s19_accounts WHERE account_id=1;

-- ---------------------------------------------------------------------
-- [19-4] SAVEPOINT — 트랜잭션 안의 부분 되돌리기
-- ---------------------------------------------------------------------
START TRANSACTION;
UPDATE s19_accounts SET balance = balance - 1000 WHERE account_id = 1;
SAVEPOINT after_withdraw;
UPDATE s19_accounts SET balance = balance + 1000 WHERE account_id = 3;   -- 잘못된 대상
SELECT '세이브포인트 롤백 전' AS step, account_id, balance
FROM s19_accounts WHERE account_id IN (1,3) ORDER BY account_id;

ROLLBACK TO SAVEPOINT after_withdraw;   -- 3번 입금만 취소, 1번 출금은 유지
SELECT '세이브포인트 롤백 후' AS step, account_id, balance
FROM s19_accounts WHERE account_id IN (1,3) ORDER BY account_id;
ROLLBACK;   -- 전체 취소 (실습이므로 원상복구)

-- ---------------------------------------------------------------------
-- [19-5] DDL 은 암묵적 커밋을 일으킨다 (함정)
-- ---------------------------------------------------------------------
-- START TRANSACTION 도중에 CREATE/ALTER/DROP/TRUNCATE 같은 DDL 을 실행하면
-- 진행 중이던 트랜잭션이 "그 직전에" 자동 커밋되어 버립니다. ROLLBACK 이 안 먹습니다.
-- 아래는 개념만 보여주는 예시입니다(실제로 돌리면 앞 UPDATE 가 커밋됨).
--
-- START TRANSACTION;
-- UPDATE s19_accounts SET balance = 1 WHERE account_id = 4;
-- CREATE TABLE s19_tmp (x INT);   -- ← 여기서 위 UPDATE 가 암묵 커밋됨!
-- ROLLBACK;                        -- UPDATE 는 이미 커밋돼서 취소 안 됨
-- DROP TABLE s19_tmp;

-- ---------------------------------------------------------------------
-- [19-6] 현재 격리수준과 락 관련 설정 확인
-- ---------------------------------------------------------------------
SELECT @@transaction_isolation    AS isolation,   -- MySQL 기본값: REPEATABLE-READ
       @@autocommit               AS autocommit,
       @@innodb_lock_wait_timeout AS lock_timeout_sec;

-- 격리수준은 세션 단위로만 바꾸세요 (GLOBAL 금지 — 다른 사용자에게 영향).
SET SESSION transaction_isolation = 'READ-COMMITTED';
SELECT @@transaction_isolation AS after_change;
SET SESSION transaction_isolation = 'REPEATABLE-READ';   -- 원복
SELECT @@transaction_isolation AS restored;

-- 최종 상태 확인
SELECT account_id, owner, balance FROM s19_accounts ORDER BY account_id;

-- =====================================================================
-- Step 19 — 두 세션 실습 : 세션 A (터미널 1)
-- ---------------------------------------------------------------------
-- 이 파일은 "통째로 실행"하지 마세요.
-- 터미널을 두 개 열고, README 의 실행 순서 표에 따라
-- [A-1], [A-2] ... 블록을 하나씩 복사해서 실행합니다.
--
-- 먼저 두 터미널 모두에서 접속하세요:
--   mysql -h127.0.0.1 -P3307 -ulearner -plearn1234 shop
-- 그리고 setup.sql 을 한 번 실행해 두세요 (둘 중 아무 터미널에서나).
-- =====================================================================
USE shop;

-- =====================================================================
-- 시나리오 1 : REPEATABLE READ 에서 반복 읽기 (기본값) — 값이 안 바뀐다
-- =====================================================================
-- [A-1] 스냅샷을 여는 첫 읽기
SET SESSION transaction_isolation = 'REPEATABLE-READ';
START TRANSACTION;
SELECT balance FROM s19_accounts WHERE account_id = 1;   -- 100000

-- ... 여기서 B-1 을 실행 (B가 +999 하고 COMMIT) ...

-- [A-2] 같은 걸 다시 읽는다 → B가 커밋했는데도 100000 그대로 (내 스냅샷)
SELECT balance FROM s19_accounts WHERE account_id = 1;   -- 여전히 100000
COMMIT;

-- [A-3] 트랜잭션을 끝낸 뒤 다시 읽으면 그제서야 B의 변경이 보인다
SELECT balance FROM s19_accounts WHERE account_id = 1;   -- 100999


-- =====================================================================
-- 시나리오 2 : READ COMMITTED 에서는 반복 읽기가 흔들린다
-- =====================================================================
-- (실습 전 값 리셋: UPDATE s19_accounts SET balance=100000 WHERE account_id=1;)
-- [A-4]
SET SESSION transaction_isolation = 'READ-COMMITTED';
START TRANSACTION;
SELECT balance FROM s19_accounts WHERE account_id = 1;   -- 100000

-- ... 여기서 B-2 실행 (B가 +999 하고 COMMIT) ...

-- [A-5] 다시 읽으면 이번엔 바뀐 값이 보인다 (non-repeatable read 발생)
SELECT balance FROM s19_accounts WHERE account_id = 1;   -- 100999
COMMIT;
SET SESSION transaction_isolation = 'REPEATABLE-READ';   -- 원복


-- =====================================================================
-- 시나리오 3 : 배타락(FOR UPDATE) — A가 잡으면 B는 기다린다
-- =====================================================================
-- [A-6] seat 1 을 배타락으로 잠근다 (커밋 전까지 계속 쥐고 있음)
START TRANSACTION;
SELECT seat_id, seat_no, status FROM s19_seats WHERE seat_id = 1 FOR UPDATE;

-- ... 여기서 B-3(NOWAIT), B-4(SKIP LOCKED), B-5(기본 대기) 를 실행해 본다 ...

-- [A-7] 잠금을 푼다 → B-5 가 그제서야 깨어난다
COMMIT;


-- =====================================================================
-- 시나리오 4 : 데드락 — 서로 상대가 쥔 자원을 기다린다
-- =====================================================================
-- (값 리셋 권장)
-- [A-8] account 1 을 먼저 잠근다
START TRANSACTION;
UPDATE s19_accounts SET balance = balance - 1 WHERE account_id = 1;

-- ... 여기서 B-6 실행 (B는 account 2 를 잠근다) ...

-- [A-9] 이제 account 2 를 잠그려 한다 → B가 쥐고 있어 대기
UPDATE s19_accounts SET balance = balance - 1 WHERE account_id = 2;
-- ↑ 이 순간 B-7 이 account 1 을 요청하면 데드락!
--   InnoDB 가 한쪽을 희생자로 골라 ERROR 1213 을 던지고,
--   살아남은 쪽(보통 A)은 여기서 정상 진행됩니다.
COMMIT;

-- =====================================================================
-- Step 19 — 두 세션 실습 : 세션 B (터미널 2)
-- ---------------------------------------------------------------------
-- 통째로 실행하지 마세요. README 순서 표에 따라 [B-1], [B-2] ... 를
-- 하나씩 복사해 실행합니다. (세션 A 와 번갈아 가며)
-- =====================================================================
USE shop;

-- =====================================================================
-- 시나리오 1 : A가 REPEATABLE READ 로 읽는 동안 B가 값을 바꾼다
-- =====================================================================
-- [B-1] A-1 실행 후에 실행. B는 별도 트랜잭션으로 값을 바꾸고 즉시 커밋.
UPDATE s19_accounts SET balance = balance + 999 WHERE account_id = 1;
COMMIT;
SELECT balance FROM s19_accounts WHERE account_id = 1;   -- 100999 (B 입장)


-- =====================================================================
-- 시나리오 2 : READ COMMITTED 대비 (값 리셋 후 진행)
-- =====================================================================
-- 값 리셋:
UPDATE s19_accounts SET balance = 100000 WHERE account_id = 1;

-- [B-2] A-4 실행 후에 실행
UPDATE s19_accounts SET balance = balance + 999 WHERE account_id = 1;
COMMIT;


-- =====================================================================
-- 시나리오 3 : A가 seat 1 을 잠근 상태에서 B의 세 가지 반응
-- =====================================================================
-- [B-3] NOWAIT : 잠긴 행을 만나면 기다리지 않고 즉시 에러 (ERROR 3572)
SELECT seat_id, seat_no FROM s19_seats WHERE seat_id = 1 FOR UPDATE NOWAIT;

-- [B-4] SKIP LOCKED : 잠긴 seat 1 은 건너뛰고, 다음 FREE 좌석을 잡는다
START TRANSACTION;
SELECT seat_id, seat_no FROM s19_seats
 WHERE status = 'FREE'
 ORDER BY seat_id
 LIMIT 2
 FOR UPDATE SKIP LOCKED;      -- seat 1 을 건너뛰고 2,3 을 반환
COMMIT;

-- [B-5] 기본 동작 : 옵션 없이 FOR UPDATE 하면 A가 커밋할 때까지 "대기"한다
--       A-7(COMMIT) 을 실행하는 순간 이 쿼리가 깨어나 결과를 낸다.
SELECT NOW(6) AS 시작;
START TRANSACTION;
SELECT seat_id, seat_no FROM s19_seats WHERE seat_id = 1 FOR UPDATE;   -- A가 커밋할 때까지 멈춰 있음
SELECT NOW(6) AS 획득;
COMMIT;


-- =====================================================================
-- 시나리오 4 : 데드락
-- =====================================================================
-- [B-6] A-8 실행 후에 실행. B는 account 2 를 먼저 잠근다.
START TRANSACTION;
UPDATE s19_accounts SET balance = balance - 1 WHERE account_id = 2;

-- [B-7] 이제 account 1 을 잠그려 한다 → A가 쥐고 있어 대기.
--       그런데 A(A-9)도 account 2 를 기다리는 중이라 서로 물림 = 데드락.
--       InnoDB 가 B를 희생자로 골라 아래 에러를 던진다:
--       ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
UPDATE s19_accounts SET balance = balance - 1 WHERE account_id = 1;
-- 데드락으로 롤백되었으므로 트랜잭션을 다시 시작해야 한다.
ROLLBACK;

-- =====================================================================
-- Step 19 — 트랜잭션과 락  exercise.sql
-- ---------------------------------------------------------------------
-- 먼저 setup.sql 을 실행하세요.
-- [문제 3][문제 4][문제 5] 는 터미널 두 개가 필요합니다.
-- 공용 테이블은 절대 건드리지 말고 s19_* 사본만 쓰세요.
-- =====================================================================
USE shop;

-- ---------------------------------------------------------------------
-- [문제 1] 안전한 이체
--   account 4 (최영희, 잔액 0) 에서 account 1 로 10000원을 이체하려 합니다.
--   잔액이 부족하면 이체를 취소(ROLLBACK)해야 합니다.
--   트랜잭션을 열고, 출금 대상의 잔액을 확인한 뒤,
--   부족하면 ROLLBACK 하는 흐름을 작성하세요.
--   (힌트: 잔액이 0이므로 이 이체는 취소되어야 합니다)
-- ---------------------------------------------------------------------
-- 여기에 작성


-- ---------------------------------------------------------------------
-- [문제 2] SAVEPOINT
--   한 트랜잭션 안에서 account 1 에서 3000 출금 → SAVEPOINT →
--   account 2 에 5000 입금(실수로 많이 넣음) → 그 입금만 취소 →
--   account 2 에 3000 입금(올바르게) → COMMIT.
--   최종적으로 1은 -3000, 2는 +3000 이 되어야 합니다.
-- ---------------------------------------------------------------------
-- 여기에 작성


-- ---------------------------------------------------------------------
-- [문제 3] 재고 선점 (두 세션)
--   두 터미널에서 각각 seat 2 를 FOR UPDATE 로 잠그고 BOOKED 로 바꾸려 합니다.
--   A 가 먼저 잠근 뒤 커밋하지 않으면 B 는 어떻게 되나요?
--   실제로 실행해 보고, B 가 언제 깨어나는지 관찰하세요.
--   (session-a.sql / session-b.sql 의 [A-6]~[A-7], [B-5] 를 seat 2 로 바꿔 응용)
-- ---------------------------------------------------------------------
-- 여기에 작성 (관찰 결과를 주석으로)


-- ---------------------------------------------------------------------
-- [문제 4] 작업 큐 (두 세션)
--   두 워커(A, B)가 동시에 FREE 좌석을 하나씩 집으려 합니다.
--   SKIP LOCKED 를 써서 서로 다른 좌석을 잡도록 각 세션의 쿼리를 작성하세요.
--   (A 가 seat 1, B 가 seat 2 를 잡아야 함)
-- ---------------------------------------------------------------------
-- 여기에 작성


-- ---------------------------------------------------------------------
-- [문제 5] 데드락 방지 (두 세션)
--   session 예제는 A: 1→2, B: 2→1 순서로 잠가 데드락이 났습니다.
--   두 세션 모두 "account_id 오름차순"으로 잠그도록 바꾸면 데드락이 안 납니다.
--   B 가 잠그는 순서를 어떻게 바꿔야 하는지 쿼리로 쓰세요.
-- ---------------------------------------------------------------------
-- 여기에 작성


-- ---------------------------------------------------------------------
-- [문제 6] 결과 예측 (실행 없이 먼저 답을 쓰고, 그다음 확인)
--   A: SET SESSION isolation = ?; START TRANSACTION; SELECT balance ...(100000)
--   B: UPDATE ... +500; COMMIT;
--   A: SELECT balance ... 다시
--   격리수준이 (a) REPEATABLE READ 일 때와 (b) READ COMMITTED 일 때
--   A 의 두 번째 SELECT 결과를 각각 예측하세요.
-- ---------------------------------------------------------------------
-- 여기에 답 작성 (주석)

-- =====================================================================
-- Step 19 — 트랜잭션과 락  solution.sql  (정답 + 해설)
-- ---------------------------------------------------------------------
-- setup.sql 을 먼저 실행하세요.
-- 단일 세션으로 확인 가능한 문제(1,2)만 실행 결과를 냅니다.
-- 두 세션 문제(3,4,5)는 session-a.sql / session-b.sql 로 진행하고
-- 여기서는 "정답 쿼리"와 해설만 제공합니다.
-- =====================================================================
USE shop;

-- ---------------------------------------------------------------------
-- [정답 1] 안전한 이체
--
-- 해설:
--   출금 대상 잔액을 FOR UPDATE 로 잠그고 읽어 "확인 후 결정"합니다.
--   애플리케이션이라면 IF 로 분기하겠지만, 순수 SQL 실습에서는
--   조건이 맞을 때만 UPDATE 되도록 WHERE 에 잔액 조건을 넣는 방법이 안전합니다.
--   account 4 는 잔액 0 이라 아래 UPDATE 는 0행에 영향 → 이체가 안 일어남 → ROLLBACK.
-- ---------------------------------------------------------------------
START TRANSACTION;
SELECT account_id, balance FROM s19_accounts WHERE account_id = 4 FOR UPDATE;  -- 0

-- 잔액 >= 10000 일 때만 출금되도록 WHERE 에 조건. 0행 갱신되면 이체 실패.
UPDATE s19_accounts SET balance = balance - 10000
 WHERE account_id = 4 AND balance >= 10000;
SELECT ROW_COUNT() AS withdrawn_rows;   -- 0 이면 잔액 부족

-- 실무에서는 ROW_COUNT()=0 이면 ROLLBACK. 여기서는 잔액 부족이므로 취소.
ROLLBACK;
SELECT '이체 취소됨(잔액 부족)' AS result, balance FROM s19_accounts WHERE account_id = 4;

-- ---------------------------------------------------------------------
-- [정답 2] SAVEPOINT
--
-- 해설:
--   실수 입금을 SAVEPOINT 로 되돌리고 올바른 금액을 다시 넣습니다.
--   출금(3000)은 SAVEPOINT 이전이라 유지됩니다.
-- ---------------------------------------------------------------------
START TRANSACTION;
UPDATE s19_accounts SET balance = balance - 3000 WHERE account_id = 1;
SAVEPOINT sp_withdraw;
UPDATE s19_accounts SET balance = balance + 5000 WHERE account_id = 2;   -- 실수(많이 넣음)
ROLLBACK TO SAVEPOINT sp_withdraw;                                       -- 그 입금만 취소
UPDATE s19_accounts SET balance = balance + 3000 WHERE account_id = 2;   -- 올바르게
COMMIT;

SELECT '문제2 결과' AS step, account_id, owner, balance
FROM s19_accounts WHERE account_id IN (1,2) ORDER BY account_id;
-- 이 실습으로 잔액이 변했으니 필요하면 setup.sql 을 다시 실행해 초기화하세요.

-- ---------------------------------------------------------------------
-- [정답 3] 재고 선점 (두 세션) — 정답 쿼리
--
-- 해설:
--   A 가 FOR UPDATE 로 잠그고 커밋하지 않으면, B 의 FOR UPDATE 는 A 의 COMMIT
--   (또는 lock_wait_timeout 50초)까지 "대기"합니다. A 가 커밋하면 B 가 깨어나
--   이미 BOOKED 로 바뀐 값을 보게 됩니다.
-- ---------------------------------------------------------------------
-- 세션 A:
--   START TRANSACTION;
--   SELECT * FROM s19_seats WHERE seat_id=2 FOR UPDATE;
--   UPDATE s19_seats SET status='BOOKED', booked_by='A' WHERE seat_id=2;
--   -- (잠시 대기)
--   COMMIT;
-- 세션 B (A가 커밋할 때까지 여기서 멈춤):
--   START TRANSACTION;
--   SELECT * FROM s19_seats WHERE seat_id=2 FOR UPDATE;   -- A 커밋 후 status=BOOKED 를 봄
--   COMMIT;

-- ---------------------------------------------------------------------
-- [정답 4] 작업 큐 (두 세션) — SKIP LOCKED
--
-- 해설:
--   두 워커가 같은 쿼리를 동시에 실행해도 SKIP LOCKED 덕분에 서로 다른 행을 잡습니다.
--   A 가 seat 1 을 잠그면 B 는 그걸 건너뛰고 seat 2 를 잡습니다.
-- ---------------------------------------------------------------------
-- 세션 A:
--   START TRANSACTION;
--   SELECT seat_id FROM s19_seats WHERE status='FREE'
--    ORDER BY seat_id LIMIT 1 FOR UPDATE SKIP LOCKED;   -- seat 1
--   -- (아직 커밋 안 함)
-- 세션 B:
--   START TRANSACTION;
--   SELECT seat_id FROM s19_seats WHERE status='FREE'
--    ORDER BY seat_id LIMIT 1 FOR UPDATE SKIP LOCKED;   -- seat 1 은 잠겨서 건너뜀 → seat 2
--   COMMIT;
-- 세션 A:
--   COMMIT;

-- ---------------------------------------------------------------------
-- [정답 5] 데드락 방지 — 락 순서 통일
--
-- 해설:
--   데드락의 원인은 "락 획득 순서가 엇갈린 것"입니다.
--   두 세션 모두 account_id 오름차순(1 먼저, 그다음 2)으로 잠그면
--   B 는 account 1 을 A 가 놓을 때까지 기다렸다가 순차 진행 → 데드락 없음.
-- ---------------------------------------------------------------------
-- 세션 A (그대로): UPDATE ... account_id=1;  그다음  UPDATE ... account_id=2;
-- 세션 B (수정):   UPDATE ... account_id=1;  그다음  UPDATE ... account_id=2;
--   즉 B 도 2→1 이 아니라 1→2 순서로 바꾼다.
--   (B 가 account 1 에서 먼저 대기하므로, 순환 대기가 생기지 않는다)

-- ---------------------------------------------------------------------
-- [정답 6] 결과 예측
--
--   (a) REPEATABLE READ : A 의 두 번째 SELECT = 100000 (스냅샷 유지, 변화 없음)
--   (b) READ COMMITTED  : A 의 두 번째 SELECT = 100500 (B 의 커밋이 보임)
--
--   이유: RR 은 트랜잭션 시작 시점의 스냅샷을 끝까지 유지하고,
--        RC 는 매 SELECT 마다 최신 커밋 스냅샷을 새로 뜬다.
-- ---------------------------------------------------------------------
SELECT '정답 6: RR=100000, RC=100500' AS answer;

-- =====================================================================
-- Step 19 — 트랜잭션과 락  cleanup.sql
-- ---------------------------------------------------------------------
-- 실습이 끝나면 실행하세요. 혹시 열린 트랜잭션이 있으면 먼저 롤백합니다.
-- =====================================================================
USE shop;
ROLLBACK;                 -- 열린 트랜잭션이 없으면 무해합니다
DROP TABLE IF EXISTS s19_accounts;
DROP TABLE IF EXISTS s19_seats;
SELECT 's19 cleanup 완료' AS msg;