What is the difference between mnesia:transaction/1's built-in behavior and manual retry logic you might add?

mnesia:transaction/1 itself already retries internally in one specific, narrow case: if the transaction is aborted purely because of a lock conflict that Mnesia's own internal deadlock resolution detected as safely retryable, it can re-run the transaction function automatically without the caller seeing an intermediate failure at all.

%% This may silently re-run Fun internally one or more times
%% before returning a final {atomic, Result} or {aborted, Reason}
mnesia:transaction(fun() ->
    mnesia:write(#counter{id = x, value = V + 1})
end).

What it does not do is retry for reasons outside its own lock-conflict handling — a node going down mid-transaction, a majority-option write failing due to a partition, or a genuine application-level exception inside your function all surface as a final {aborted, Reason} that your own code must decide how to handle. The practical implication: don't assume every transient failure is already retried for you; only the internal lock-conflict case is, and everything else needs your own retry strategy layered on top if that's the behavior you want.

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.