When would you use mnesia:read_lock_table/1 instead of relying on per-record locks?

Table-level locking makes sense specifically when an operation needs a consistent view of, or exclusive access to, the entire table at once — something per-record locks can't provide, since they only protect individual rows from concurrent modification while leaving the rest of the table open.

mnesia:transaction(fun() ->
    mnesia:read_lock_table(person),
    %% now guaranteed no concurrent writer can modify ANY record
    %% in this table until this transaction finishes
    Total = length(mnesia:all_keys(person))
end).

Good candidates: a bulk migration or schema transformation that needs the whole table to hold still while it works, or a consistency check/report that must see a single, unchanging snapshot across every record rather than potentially observing some records mid-update by other concurrent transactions. It's a deliberate, heavier-weight tool — using it routinely for ordinary operations would erase most of the concurrency benefit Mnesia's per-record locking otherwise provides.

Invest now in Acorns!!! 🚀
Join Acorns and get your $5 bonus!

Acorns is a micro-investing app that automatically invests your "spare change" from daily purchases into diversified, expert-built portfolios of ETFs. It is designed for beginners, allowing you to start investing with as little as $5. The service automates saving and investing. Disclosure: I may receive a referral bonus.

Invest now!!! Get Free equity stock (US, UK only)!

Use Robinhood app to invest in stocks. It is safe and secure. Use the Referral link to claim your free stock when you sign up!.

The Robinhood app makes it easy to trade stocks, crypto and more.

Webull! Receive free stock by signing up using the link: Webull signup.