Fencing Token
Nach einer Übernahme können verspätete Schreibaufrufe eines alten Inhabers eintreffen.
- GenerationGeneration: Jede Übernahme erhält eine höhere Kennung.
- PrüfungPrüfung: Die geschützte Ressource prüft jede Wirkung.
- AblehnungAblehnung: Veraltete Inhaber verlieren Schreibzugriff.
Einordnung
Warum das wichtig ist
Alte Inhaber durch Ressourcenkontrolle sicher abgrenzen.
Alte Inhaber durch Ressourcenkontrolle sicher abgrenzen.
Fencing Token: Entscheidung prüfen
Das Shop-Beispiel nutzt die bestehende gemeinsame Datenbank und sieben Module. Jede ergänzte Dienst- oder Betriebsform ist eine hypothetische Erweiterung. Für die Rechnung B-1042 erhält Worker A Token 41. Nach einer Pause läuft sein Lease ab und Worker B übernimmt mit Token 42. B speichert den geprüften Rechnungsstatus. Als A später eine alte Schreiboperation abschickt, vergleicht die Datenbank 41 mit dem gespeicherten Höchstwert 42 und lehnt den Versuch ab. Der Token muss bis zur Ressource gelangen, die die Wirkung speichert; eine Prüfung allein im Worker würde den verspäteten Aufruf nicht aufhalten.
So liest du das Bild
- Generation Generation
- Prüfung Prüfung
- Ablehnung Ablehnung
| Begriff | Bedeutung | Prüffrage |
|---|---|---|
| Generation | Jede Übernahme erhält eine höhere Kennung. | Welcher Wert ist nach der Übernahme durch Worker B gültig? |
| Prüfung | Die geschützte Ressource prüft jede Wirkung. | Wo muss der Token geprüft werden? |
| Ablehnung | Veraltete Inhaber verlieren Schreibzugriff. | Was bleibt unsicher, wenn nur der Worker seinen Token prüft? |
Nutzen & Grenzen
Hilft, wenn
- Alte Inhaber durch Ressourcenkontrolle sicher abgrenzen.
- Token bei jeder geschützten Änderung als Vorbedingung mitsenden.
Grenzen
- Ein Token ohne Prüfung am Zielsystem bietet keine Schutzwirkung.
- Monotonie muss auch nach Koordinator-Neustart und Speicherwiederherstellung erhalten bleiben.
In der Praxis
- Erzeuge zwei aufeinanderfolgende Inhaber für B-1042 und protokolliere die zugewiesenen monoton steigenden Token; prüfe, wo der höchste akzeptierte Wert dauerhaft liegt.
- Sende nach dem Speichern durch Worker B absichtlich den verspäteten Schreibversuch von Worker A mit Token 41 und erwarte eine Ablehnung durch die Datenbank.
- Wiederhole den Test nach einem Datenbankneustart und über einen zweiten Schreibpfad, damit kein Endpunkt den Tokenvergleich umgeht oder den Höchstwert verliert.
Ausführliche Erklärung lesen
Ein Fencing Token ist eine monoton steigende Kennung, die eine Ressource an eine Arbeitsgeneration bindet. Nach jeder neuen Übernahme erhält der nächste Inhaber einen größeren Wert.
Die geschützte Ressource speichert den höchsten akzeptierten Wert und weist ältere Schreibversuche zurück. Der Token schützt dadurch auch dann, wenn ein alter Prozess nach Lease-Ablauf wieder aufwacht.
Das Shop-Beispiel nutzt die bestehende gemeinsame Datenbank und sieben Module. Jede ergänzte Dienst- oder Betriebsform ist eine hypothetische Erweiterung. Für die Rechnung B-1042 erhält Worker A Token 41. Nach einer Pause läuft sein Lease ab und Worker B übernimmt mit Token 42. B speichert den geprüften Rechnungsstatus. Als A später eine alte Schreiboperation abschickt, vergleicht die Datenbank 41 mit dem gespeicherten Höchstwert 42 und lehnt den Versuch ab. Der Token muss bis zur Ressource gelangen, die die Wirkung speichert; eine Prüfung allein im Worker würde den verspäteten Aufruf nicht aufhalten. lease fencing und lease helfen, diese Entscheidung mit benachbarten Fragen zu vergleichen.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welcher Wert ist nach der Übernahme durch Worker B gültig?
Lösung mit Begründung ansehen
Token 42; ein verspäteter Schreibversuch mit Token 41 ist älter.
AnwendenAuf eine neue Lage übertragen
Wo muss der Token geprüft werden?
Lösung mit Begründung ansehen
Am Speicher oder Zielsystem, das die geschützte Wirkung dauerhaft übernimmt.
BewertenEine Alternative abwägen
Was bleibt unsicher, wenn nur der Worker seinen Token prüft?
Lösung mit Begründung ansehen
Ein pausierter alter Worker kann nach dem Wiederaufwachen weiterhin verspätet schreiben.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- The Chubby lock service (öffnet in neuem Tab)Beschreibt Sequencer mit Generation und Prüfung durch Ressourcendienste.
- How to do distributed locking (öffnet in neuem Tab)Begründet Ressourcenschutz mit Fencing Tokens.
- Managing Critical State (öffnet in neuem Tab)Behandelt kritischen Zustand und Koordination im Betrieb.