永続化 | LMSP 1.0 ドラフト

11.1 ストレージ

サービスは、状態を組み込みの SQLite データベースに保存するべきである。推奨するテーブルの構成は次のとおりである。

テーブル	内容
`service_config`	サービスの ID と設定。
`clients`	ペアリング済みクライアント、トークンのハッシュ、スコープ。
`models`	モデルのメタデータと内容のダイジェスト。
`responses`	保存済みのレスポンス。
`tasks`	非同期タスク。
`task_events`	各タスクのイベントログ。シーケンス番号付き。
`idempotency_keys`	冪等キー、リクエストのダイジェスト、結果。

モデルファイルはデータベースの外に置かなければならない。データベースが保持するのは、メタデータと内容のダイジェストだけである。

テーブル名とレイアウトは実装の選択である。クライアントが観察でき、相互運用のために必要なのは、次の 2 つの節にある動作である。

11.2 規則

サービスは、どのようなストレージを使うにしても、次のことを行う。

202 Accepted を返す前に、タスクを永続化しなければならない。
イベントのシーケンス番号とタスクの状態を、同じトランザクションで更新しなければならない。
キャンセルの遷移をアトミックにし、タスクがキャンセルされた後に完了するという競合を避けなければならない。
完了したタスクとイベントを、設定可能な保持期間の間、保持するべきである。
ログの整理の際に、未完了のタスクを削除してはならない。
起動時に、残っている queued、loading、running、cancelling のタスクを走査し、それぞれの再起動ポリシーを適用しなければならない（7.5 節）。

11.3 起動時の復旧

次の表は、残っていたタスクが、on_restart ポリシーに応じて移される状態を示す。

起動時に見つかった状態	`fail`	`retry`	`resume`
`queued`	`failed`	`queued`	`queued`
`loading`	`failed`	`queued`	`queued`
`running`	`failed`	`queued`	`running`（スナップショットから続行）
`cancelling`	`cancelled`	`cancelled`	`cancelled`

failed に移されたタスクには、エラーコード server_restarted と response.failed イベントが付く。cancelled に移されたタスクには、response.cancelled イベントが付く。新しい状態とそのイベントは、1 つのトランザクションで書き込まれる（11.2 節）。