Checkpoint, close, and rebuild the view.

After Commit succeeds conclusively, the transaction is durable without a checkpoint. A checkpoint changes recovery geometry: it moves an accepted prefix into immutable family runs and leaves only later commits in the log suffix.

Use a checkpoint to bound recovery work

The transaction log is the database-wide order of accepted commits. A checkpoint records one exact replay boundary and immutable runs for the affected families.

The library does not start checkpoint work automatically. The application observes its workload, chooses the timing, and supplies every publication identity.

Publish one explicit checkpoint

Flush accepts a family-to-run identity map, a manifest ID, a transition ID, and one deadline. The example maps family 1 to Checkpoint_Run_ID through Initial_Runs.

      DB.Flush
        (Item,
         Initial_Runs,
         First_Flush_Manifest_ID,
         First_Flush_Transition_ID,
         Timeout,
         Receipt => Flush_Info,
         Result  => Result);
      if Result = DB.Outcome_Unknown then
         DB.Resolve_Flush (Item, Flush_Info, Timeout, Result => Result);
      end if;
      Expect (Result, DB.Success, "Flush did not resolve conclusively");

The call follows four rules:

  1. Supply one fresh run ID for every nonempty family that needs a complete or suffix snapshot.
  2. Supply fresh manifest and transition IDs.
  3. Retain the receipt when the outcome is unknown.
  4. Resolve the same receipt instead of starting another Flush.

The first Flush writes complete nonempty-family runs. A later Flush appends one suffix-delta run for each affected family and retains earlier runs.

Finish work before you close

Finish or roll back every transaction and operation before Close. Keep the storage binding and its borrowed owners alive until the database closes.

After Close succeeds, discard every family handle and process-local database value. Do not carry a handle into the next database owner.

Reopen from object storage

Create fresh provider, binding, and database owners. Bind the new storage owner, then call Open with the persisted database ID.

      Binding.Bind (Storage, Store'Access, Bucket, Prefix);
      DB.Open
        (Item, Storage'Access, Demo_Database_ID, Timeout, Result => Result);
      Expect (Result, DB.Success, "database reopen failed");
      Read_And_Require
        (Item, Reopened_Read_ID, True, False, "after suffix reopen");

Open reads the current metadata pointer and validates the persisted limits and manifest. Open authenticates each referenced immutable object. It then replays only the commits after the checkpoint boundary and installs one complete view.

Listing does not establish the current database.

Recovery follows authenticated references from the metadata pointer. A cache or object listing can help discovery or garbage collection, but neither one selects visible state.

Extend the recovered database

The next chapter adds a second family while the reopened database still has a retained checkpoint and a later live suffix.