Database / Mnesia intermediate to advanced Interview questions
Why should nested transactions generally be avoided or used carefully in Mnesia?
Since a nested transaction shares the outer transaction's fate (an inner abort takes down the whole outer transaction), relying on nesting to isolate a "risky" operation from the rest doesn't actually provide the isolation you might expect from true nested/savepoint semantics in some relational databases — a failure several layers deep still unwinds everything above it.
It can also make transaction logic harder to reason about: a function written assuming it's always the top-level transaction might behave subtly differently when called from inside another transaction (locks already held by the outer transaction interacting with what the inner one requests), which can be a source of confusing bugs if the nesting isn't intentional and well understood by whoever wrote the calling code. In practice, most Mnesia code is written to run as a single, flat transaction per logical operation, only nesting incidentally when composing reusable helper functions rather than as a deliberate transaction-design tool.
More Related questions...