State persistence retains process data beyond the computation that created it. In a concurrent system, it supports recovery and availability by allowing a restarted process to inherit the state of its predecessor. section 7.0 section 9.3.3
A simple implementation extends a to-do cache with disk storage, encoding data in Erlang’s external term format. Persist the updated state only after all transformations complete, so stored data remains consistent. section 7.3 section 9.3.3
Persisting an updated to-do list
After adding an entry, store the resulting list before returning the new server state. A later process can restore that list when it starts. section 9.3.3
Choose the persistence mechanism and recovery policy with these boundaries in mind:
- Disk persistence survives process termination but introduces a consistency responsibility: save only completed transformations. section 7.3 section 9.3.3
- Public ETS tables provide fast in-memory state persistence across process restarts, but state disappears with the relevant runtime and complicates distribution. section 10.3.3
- Persisted invalid state can make every restart fail; when possible, recover with clean state or reconstruct it from dependent processes. section 9.3.3 section 10.3.3
def handle_cast({:add_entry, new_entry}, {name, todo_list}) do
new_list = Todo.List.add_entry(todo_list, new_entry)
Todo.Database.store(name, new_list) #1
{:noreply, {name, new_list}}
end
Shows the write-after-update sequence used to persist a modified to-do list. section 9.3.3
iex(1)> todo_list = :ets.new(:todo_list, [:bag])
iex(2)> :ets.insert(todo_list, {~D[2023-05-24], "Dentist"})
iex(3)> :ets.insert(todo_list, {~D[2023-05-24], "Shopping"})
iex(4)> :ets.insert(todo_list, {~D[2023-05-30], "Dentist"})
Demonstrates creating an ETS table and inserting several to-do entries as in-memory state. section 10.3.3
