Quiz: Reject a Late Courier's Completion Stamp

A의 임대가 1000ms에 끝나고 B가 같은 시각에 재선점했습니다. A가 1001ms에 완료를 요청하면?

• A가 먼저 시작했으므로 B의 현재 선점을 완료 처리한다
• 수량이 같다면 A와 B의 결과를 모두 완료로 승인한다
• A의 옛 토큰은 False로 거절하고 B의 상태를 보존한다
• A의 요청이 늦었으므로 해당 업무 행 전체를 삭제한다

작업자 이름이 worker-1로 같은 프로세스가 재시작했습니다. owner만 대조하면 부족한 이유는?

• 이름이 같으면 SQLite가 두 프로세스의 연결을 하나로 합친다
• 이름이 같으면 임대 만료 시각이 자동으로 같은 값이 된다
• 이름이 같으면 완료한 모든 업무를 새 프로세스가 재접수한다
• 같은 이름의 이전 실행과 현재 선점 세대를 구분하지 못한다

두 프로세스가 대기 업무 하나를 동시에 claim합니다. 선택과 갱신을 어떻게 묶나요?

• BEGIN IMMEDIATE 안에서 선택·횟수 증가·임대를 함께 커밋한다
• 트랜잭션 밖에서 둘 다 선택한 뒤 각각 임대 상태로 덮어쓴다
• 각 프로세스의 메모리 잠금만 잡고 DB 선택은 독립 실행한다
• 전송을 먼저 한 뒤 수신 응답이 빠른 쪽이 임대를 저장한다

send 콜백이 응답을 기다리는 동안 다른 작업자가 새 업무를 enqueue할 수 있어야 합니다. 필요한 구조는?

• HTTP 응답까지 선점 트랜잭션을 열어 원자성을 보장한다
• 선점 커밋 후 전송하고 결과 기록은 별도 트랜잭션으로 한다
• 전송 동안 모든 작업자가 같은 연결을 공유하고 쓰기를 미룬다
• 전송 전에 큐를 삭제하고 완료한 뒤 새 DB를 생성한다

큐가 오래된 token의 finish를 거절합니다. 이 사실만으로 외부 재고 서버의 중복 효과도 막았나요?

• 그렇다. SQLite의 토큰 비교가 외부 DB에도 자동 적용된다
• 그렇다. 두 HTTP 요청이 같은 큐 행에서 나왔으면 병합된다
• 아니다. 수신 측 업무 ID 중복 제거 등 별도 계약이 필요하다
• 아니다. 큐의 토큰을 매 재시도마다 0으로 바꿔야 해결된다

now=900, lease_ms=1000, deadline=1200인 업무를 선점합니다. lease_until은?

• 1900으로 두고 완료 시 최초 마감을 늘린다
• 1000으로 두고 모든 시각을 프로세스 시작 기준으로 바꾼다
• 900으로 두고 선점 직후 다른 작업자가 가져가게 한다
• 1200으로 제한하여 업무 마감 이후 권리를 주지 않는다