测验：当变更一直等待

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

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

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

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

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

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

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

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

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

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

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

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