3
votes

I create a mnesia table, e.g.

mnesia:create_table(mytable, [{ram_copies, node()}, {local_content,true}], 
                              {attributes, [col1,col2]}]).

Because local_content=true, so that it cannot share data with other nodes, and it is a ram_copies table.

I believe I can do the same thing with an ets table, as below.

ets:new(mytable,[named_table, public]).

I guess from performance point of view, they are similar.

I am wondering what are the differences between the two tables, from semantics point of view?

1

1 Answers

2
votes

The table is the back-end for the storage. The difference is in the transaction handling supported by Mnesia, but not ETS.

In fact, the transaction handling of Mnesia is dependent upon the transaction context used:

  • transaction: run a series of database operations as a single functional block. The whole block will run on all nodes or none of them; it succeeds entirely or fails entirely. This type of activity context is partially asynchronous: it will be synchronous for operations on the local node, but it will only wait for the confirmation from other nodes that they will commit the transaction, not that they have done it.
  • sync_transaction: pretty much the same as transaction, but it is synchronous across all nodes.
  • async_dirty: bypasses all the transaction protocols and locking activities (note that it will, however, wait for active transactions to finish before proceeding)
  • sync_dirty: will wait for the confirmation that things went fine on remote nodes, but will still stay out of all locking or transaction contexts.
  • ets: basically a way to bypass everything Mnesia does and do series of raw operations on the underlying ETS tables, if there are any. No replication will be done.