Ticketing Anfrage-×-Schlüsselzustand-Matrix
A (Acquire)
| Schlüsselzustand | Serveraktion | Antwort | Zeitpunkt |
|---|---|---|---|
| Nicht registriert | Registrieren (Ablauf = jetzt+lease), Token ausstellen | A+token+owner+key | Sofort |
| Registriert + abgelaufen | Erneuern (jetzt+lease), neues Token | A+token+owner+key | Sofort |
Registriert + gültiger Holder + wait=0 | Nicht einreihen | T+owner+key | Sofort |
Registriert + gültiger Holder + wait>0 | Einreihen, Antwort offen | A oder T+owner+key | Erwerb durch release/expiry oder T bei wait-Ablauf |
| Queue- oder Server-Kapazität am Limit | Nicht einreihen | B+owner+key | Sofort |
- Der Release-Pfad ist FIFO-fair: Macht der Inhaber
R, wird direkt an den Wartenden an der Spitze der Warteschlange übergeben (kein erneuter Wettbewerb, ein neues Token). - Nur der Ablaufpfad ist nicht FIFO.
- Ein
owner, der dem aktuellen Holder entspricht, wird nicht besonders behandelt. Er berechtigt weder zur Rückgabe eines active token noch zur Lease-Erneuerung; die normalen Regeln für gehaltene Keys gelten. - Antworten können außerhalb der Request-Reihenfolge eintreffen; Clients matchen nach dem echoed
owner.R(Release)
| Schlüsselzustand | Serveraktion | Antwort |
|---|---|---|
| Registriert + Token stimmt überein, hat Wartende | Direkt an den Wartenden an der Spitze übergeben (neues Token) | R+token+key |
| Registriert + Token stimmt überein, keine Wartenden | Schlüssel löschen | R+token+key |
| Registriert + Token weicht ab | Nichts (Sperre bleibt bestehen) | N+token+key |
| Nicht registriert | Nichts | N+token+key |
Wann der Ablauf verarbeitet wird
- Der Single-Modus verarbeitet den Ablauf träge (lazy) — ein abgelaufener Schlüssel wird vom nächsten Acquire an Ort und Stelle übernommen (zweite Zeile oben), und ein separater 5-Sekunden-Sweep räumt abgelaufene Schlüssel ohne Wartende auf. Daher kann ein Release auf einem Schlüssel, der abgelaufen, aber noch nicht aufgeräumt ist,
RstattNerhalten. - Im Cluster-Modus wartet der Leader auf den nächsten Eintrag eines tokenprüfenden Deadline-Min-Heaps und committet dann den
Expire-Befehl per Konsens, bevor der Key verschwindet. Clock-Unterschiede teilen so den Lock-Zustand nicht.