예약 도구에서 제일 나쁜 실패는 예약이 안 되는 게 아니다.
두 사람에게 다 "예약되셨습니다"를 보내는 것이다. 안 되면 다시 하면 되는데, 둘 다 됐다고 하면 그 다음은 사람이 전화로 해결한다.
두 처리기, 같은 설명
이 샘플에는 슬롯을 잡는 처리기가 둘 있다. 말로 설명하면 완전히 같다 — 비었는지 보고, 비었으면 잡는다.
한쪽은 이렇다.
// 1. Look.
final free = slot.takenBy == null;
// 2. Anything at all in here — a database round trip, a payment check, a
// log write, a lookup of the customer's name — hands control to
// whatever else was in flight.
await Future<void>.delayed(Duration.zero);
// 3. Write, using what was true in step 1.
if (free) { slot.takenBy = who; ... }다른 쪽은 이렇다.
if (slot.takenBy != null) {
return '$at is already taken by ${slot.takenBy}';
}
slot.takenBy = who;
slot.confirmations.add(who);
await Future<void>.delayed(Duration.zero); // the slow part, after the claim같은 await 가 위치만 다르다. 앞엣것은 확인과 기록 사이에 있고, 뒤엣것은 기록 뒤에 있다.
그리고 그 위치가 이중 예약을 만든다.
실제로 일어나게 만든다
unsafe -> Suh: "CONFIRMED 10:30 for Suh"
unsafe -> Park: "CONFIRMED 10:30 for Park"
unsafe result: 1 slot(s) confirmed to more than one person
화면이 정확히 현실의 증상을 보여준다. 슬롯 주인은 Park 한 명인데, "예약됐다"는 말을 들은 사람은 둘이다.
이게 실제 가게에서 벌어지는 모양이다. 장부는 한 명이고, 문 앞에는 두 명이 온다.
그래서 서버가 확정을 보낸 사람을 다 기억한다.
/// Everybody who has ever been told they got this slot. In a correct
/// booking system this never has more than one name in it, which is exactly
/// why it is worth keeping.
final confirmations = <String>[];정상이면 항상 한 명짜리 목록이다. 항상 한 명이어야 하는 목록이야말로 세어 볼 값어치가 있다.
그리고 안 일어나게 만든다
같은 두 사람, 같은 시간, 틈만 닫고.
--- cleared, same two people, same slot, gap closed ---
safe -> Suh: "CONFIRMED 10:30 for Suh"
safe -> Park: "10:30 is already taken by Suh"
safe result: nobody was told yes twice
거절이 "실패했습니다"가 아니라 "Suh 님이 잡으셨습니다"다. 두 번째 사람이 알아야 하는 건 자기가 실패했다는 사실이 아니라 그 자리가 나갔다는 사실이고, 그래야 다음 시간을 고른다.