퀴즈: 오래 기다리는 변경

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. lock_timeout=100ms인 UPDATE를 배치에서 12번 실행합니다. 배치 전체가 100ms 안에 끝난다고 할 수 있나요?

   1. 아니다. 개별 잠금 획득 대기의 한도이며 전체 경과 시간 예산은 별도다
   2. 그렇다. 첫 UPDATE부터 마지막 COMMIT까지 하나의 타이머로 묶인다
   3. 그렇다. 한 트랜잭션이면 연결 시간과 응답 전송도 같은 한도에 포함된다
   4. 아니다. 100ms는 오류 후 재시도 사이에 반드시 기다려야 하는 시간이다

2. 잠금 한도 800ms와 문장 한도 100ms를 함께 설정했습니다. 잠금 대기가 길어질 때 먼저 나타날 수 있는 결과는?

   1. 800ms 잠금 한도가 있으므로 문장 한도는 잠금 대기 중 중지된다
   2. 문장 처리 시간이 먼저 초과되어 잠금 전용 오류보다 문장 취소가 먼저 난다
   3. 문장 한도가 더 짧으므로 드라이버가 두 값을 자동으로 맞바꾼다
   4. 두 한도의 합인 900ms까지 기다린 뒤에만 첫 오류를 반환한다

3. 잠금 한도를 세션 범위로 설정한 함수가 오류로 롤백될 때 원래 값으로 돌아왔습니다. 설정 누수가 없다는 충분한 시험인가요?

   1. 충분하다. 한 번 롤백된 설정은 이후 성공 때도 자동으로 세션에서 삭제된다
   2. 충분하다. DB가 살아 있는 동안 연결 풀은 설정을 사용하지 않는다
   3. 아니다. 성공 커밋 뒤에도 설정이 남지 않는지 같은 연결에서 검사해야 한다
   4. 아니다. 실패 때 원복되지 않도록 세션 설정을 고정하는 것이 우선이다

4. 두 번째 주문의 잠금 대기 시간이 초과됐습니다. 첫 주문의 복구도 사라졌는지 어떻게 판단하나요?

   1. 예외가 발생했다면 첫 UPDATE도 반드시 실행되지 않았다고 판단한다
   2. 오류 메시지에 timeout이 있으면 전체 트랜잭션이 없었다고 기록한다
   3. 두 번째 행의 상태만 확인하고 첫 행은 성공 기록으로 남긴다
   4. 바깥 트랜잭션 롤백 뒤 독립 조회로 첫 행과 대조군까지 확인한다

5. retry_undo의 attempts=3일 때 첫 두 번은 잠금 오류, 세 번째도 잠금 오류입니다. 이 수업의 올바른 호출 수는?

   1. action 3회, pause 2회 후 마지막 잠금 오류를 전달한다
   2. 최초 실행 외 재시도가 3번이므로 action 4회와 pause 3회다
   3. 소진 오류를 숨기기 위해 마지막에 action을 한 번 더 실행한다
   4. pause를 세 번 호출한 뒤 False를 성공 영수증처럼 반환한다

6. 첫 시도는 잠금 오류였지만 잠금 해제 뒤 주문 버전이 달라져 Conflict가 났습니다. 다음 행동은?

   1. 현재 버전으로 기대값을 교체하여 남은 횟수만큼 자동 재시도한다
   2. 재시도를 멈추고 달라진 승인 전제를 담당자에게 전달한다
   3. 같은 건수만 유지되면 원래 고객 조건을 빼고 적용한다
   4. 새 보상 ID를 발급하여 원래 변경에 대한 중복 제한을 피한다