Persistencia | LMSP 1.0 Borrador

11.1 Almacenamiento

Un servicio DEBERÍA guardar su estado en una base de datos SQLite integrada. Un conjunto de tablas sugerido:

Tabla	Contenido
`service_config`	Identidad y configuración del servicio.
`clients`	Clientes emparejados, hashes de tokens y ámbitos.
`models`	Metadatos de los modelos y resúmenes criptográficos de su contenido.
`responses`	Respuestas almacenadas.
`tasks`	Tareas asíncronas.
`task_events`	El registro de eventos de cada tarea, con números de secuencia.
`idempotency_keys`	Claves de idempotencia, resúmenes de solicitudes y resultados.

Los archivos de modelo DEBEN quedar fuera de la base de datos. La base de datos contiene solo metadatos y resúmenes criptográficos del contenido.

Los nombres y la disposición de las tablas son una decisión de implementación. Lo que los clientes pueden observar, y lo que tiene que ser interoperable, es el comportamiento descrito en las dos secciones siguientes.

11.2 Reglas

Sea cual sea el almacenamiento que use un servicio, este:

DEBE persistir una tarea antes de devolver 202 Accepted.
DEBE actualizar los números de secuencia de los eventos y el estado de la tarea en la misma transacción.
DEBE hacer atómica la transición de cancelación, para evitar la condición de carrera de una tarea que se cancela y luego se completa.
DEBERÍA conservar las tareas y los eventos terminados durante un período de retención configurable.
NO DEBE eliminar tareas sin terminar durante la limpieza de registros.
DEBE, al arrancar, examinar las tareas queued, loading, running y cancelling que hayan quedado, y aplicar la política de reinicio de cada una (sección 7.5).

11.3 Recuperación al arrancar

La tabla muestra el estado al que pasa una tarea que quedó pendiente, según su política on_restart:

Estado encontrado al arrancar	`fail`	`retry`	`resume`
`queued`	`failed`	`queued`	`queued`
`loading`	`failed`	`queued`	`queued`
`running`	`failed`	`queued`	`running`, continuando desde la instantánea
`cancelling`	`cancelled`	`cancelled`	`cancelled`

Una tarea que pasa a failed recibe el código de error server_restarted y un evento response.failed. Una tarea que pasa a cancelled recibe un evento response.cancelled. El nuevo estado y su evento se escriben en una sola transacción (sección 11.2).