Persistance
- Normative
- Brouillon 1.0
- Mis à jour
- Afficher en Markdown
11.1 Stockage
Un service DEVRAIT conserver son état dans une base SQLite intégrée. Un jeu de tables suggéré :
| Table | Contenu |
|---|---|
service_config |
Identité et configuration du service. |
clients |
Clients appairés, empreintes des jetons et portées. |
models |
Métadonnées des modèles et empreintes de leur contenu. |
responses |
Réponses stockées. |
tasks |
Tâches asynchrones. |
task_events |
Le journal des événements de chaque tâche, avec des numéros de séquence. |
idempotency_keys |
Clés d’idempotence, empreintes des requêtes et résultats. |
Les fichiers de modèles DOIVENT rester en dehors de la base de données. La base ne contient que des métadonnées et des empreintes de contenu.
Les noms et la structure des tables relèvent de l’implémentation. Ce que les clients peuvent observer, et ce qui doit être interopérable, c’est le comportement décrit dans les deux sections suivantes.
11.2 Règles
Quel que soit le stockage utilisé, un service :
- DOIT persister une tâche avant de renvoyer
202 Accepted. - DOIT mettre à jour les numéros de séquence des événements et l’état de la tâche dans la même transaction.
- DOIT rendre atomique la transition d’annulation, pour éviter la situation de concurrence d’une tâche annulée puis terminée.
- DEVRAIT conserver les tâches et les événements terminés pendant une durée de conservation configurable.
- NE DOIT PAS supprimer les tâches inachevées lors du nettoyage des journaux.
- DOIT, au démarrage, parcourir les tâches
queued,loading,runningetcancellingrestantes, et appliquer la politique de redémarrage de chacune (section 7.5).
11.3 Reprise au démarrage
Le tableau indique l’état vers lequel une tâche restante est déplacée, selon sa politique on_restart :
| État trouvé au démarrage | fail |
retry |
resume |
|---|---|---|---|
queued |
failed |
queued |
queued |
loading |
failed |
queued |
queued |
running |
failed |
queued |
running, en reprenant à partir de l’instantané |
cancelling |
cancelled |
cancelled |
cancelled |
Une tâche déplacée vers failed reçoit le code d’erreur server_restarted et un événement response.failed. Une tâche déplacée vers cancelled reçoit un événement response.cancelled. Le nouvel état et son événement sont écrits dans une seule transaction (section 11.2).