classy_table ¶This module implements a standalone minimalist analogue of mnesia’s local_data table with disc_copies storage.
It is used to store classy’s own persistent data. Other applications can also use it for data that doesn’t require replication and is not written too frequently.
Classy tables consist of a RAM cache backed by ETS and a durable write ahead log. Durable operations (write, delete, atomically) are immediately appended to the WAL, while dirty mutations (dirty_write, dirty_delete) only mark certain keys as dirty. All dirtied keys are flushed to WAL only when table is flushed.
The WAL is periodically compacted when its “badness” exceeds the configured threshold. Badness is calculated as a difference between the number of table elements and length of the log. WAL compaction is a blocking operation: all table mutations get blocked while it goes on. Compaction time is proportional to the number of elements stored in the table.
Because of this design, frequent mutations of the same key, e.g.
classy_table:write(Tab, foo, 1), classy_table:write(Tab, foo, 2), classy_table:write(Tab, foo, 3), ...
are rather inefficient.
flush is called or the table server terminates.
They are meant for the situations where some keys are frequently updated,
but these updates can be lost.
There is no automatic flushing of dirty operations,
the business code must call flush(Table) function explicitly.
If it fails to do so, all work for persisting the data will be done on terminate or after a durable mutation, which may be risky or lead to unexpected results.
classy_table:lookup/2 or plain ets queries.
So, do not use classy tables as a synchronization mechanism between different processes.
on_update callback is executed before operations are persisted to the WAL.
As such, it is not a reliable way to mirror the state of a classy table to other storage.
on_update operations block the table server.
They must not contain any sort of heavy or long-running tasks.