Persistenz

11.1 Speicherung

Ein Dienst SOLLTE seinen Zustand in einer eingebetteten SQLite-Datenbank halten. Ein vorgeschlagener Satz von Tabellen:

Modelldateien MÜSSEN außerhalb der Datenbank bleiben. Die Datenbank enthält nur Metadaten und Inhalts-Digests.

Tabellennamen und Aufbau sind eine Implementierungsentscheidung. Was Clients beobachten können und was interoperabel sein muss, ist das Verhalten in den nächsten beiden Abschnitten.

11.2 Regeln

Welchen Speicher ein Dienst auch verwendet, er:

• MUSS eine Aufgabe persistieren, bevor er 202 Accepted zurückgibt.
• MUSS Ereignis-Sequenznummern und Aufgabenstatus in derselben Transaktion aktualisieren.
• MUSS den Abbruchübergang atomar machen, um die Race Condition einer Aufgabe zu vermeiden, die abgebrochen und dann abgeschlossen wird.
• SOLLTE beendete Aufgaben und Ereignisse für eine konfigurierbare Aufbewahrungsdauer vorhalten.
• DARF NICHT unfertige Aufgaben bei der Protokollbereinigung löschen.
• MUSS beim Start die übrig gebliebenen Aufgaben queued, loading, running und cancelling durchsehen und die Neustartrichtlinie jeder einzelnen anwenden (Abschnitt 7.5).

11.3 Wiederherstellung beim Start

Die Tabelle zeigt den Zustand, in den eine übrig gebliebene Aufgabe gemäß ihrer on_restart-Richtlinie überführt wird:

Eine Aufgabe, die nach failed überführt wird, erhält den Fehlercode server_restarted und ein response.failed-Ereignis. Eine Aufgabe, die nach cancelled überführt wird, erhält ein response.cancelled-Ereignis. Der neue Zustand und sein Ereignis werden in einer Transaktion geschrieben (Abschnitt 11.2).