[erlang-questions] non-atomic nature of mnesia:dirty_update_counter

[Matthew Sackman]

FWIW, in Rabbit we do all updates/writes in sync_transaction blocks, but
do use dirty_read, dirty_select and friends (i.e. no dirty_writes or
dirty_deletes[0]). Hopefully this counts as safely getting the speed we
want, safely. We are in a very read-dominated scenario though.

I also concur with the pain with using mnesia in a clustered environment
generally: whilst I have no problem with the idea of going for
consistency and availability and not coping with partitions,
nevertheless, things like dealing with upgrading schemas and such in an
clustered setup where you have not all nodes up, is incredibly tricky:
we have to write out files so that we know which node went down last
thus is safe to start mnesia on, on recovery etc etc. It's all far more
painful than we'd like, but that said, these are very hard problems to
get right.

And it'd be a million times worse with something SQL based. And we
really need transactions currently, which cuts out a number of the
popular key/value stores.

Matthew

[0] Having just grepped the code, I find that's not quite right, but
it's certainly in a non critical place!