mnesia question

[Renyi Xiong]

Thanks guys,
It's really helpful for us to understand how Mnesia works.

1.My understanding is when one node initiates a write operation it sends a 
message to each of the replicas at same time and doesn't care the write 
transaction status on other replicas. It's up to the transaction handler on 
each node to handle the write transaction separately. Is that right?

2.How do I know the write operation succeeds on at least on of the replicas 
including the one which initiates it?

Thanks,
Renyi.

----- Original Message ----- 
From: "Hakan Mattsson" <hakan@REDACTED>
To: "Ulf Wiger (AL/EAB)" <ulf.wiger@REDACTED>
Cc: "Renyi Xiong" <renyix1@REDACTED>; <erlang-questions@REDACTED>; 
<rxiong@REDACTED>
Sent: Monday, February 13, 2006 8:54 AM
Subject: RE: mnesia question


On Mon, 13 Feb 2006, Ulf Wiger (AL/EAB) wrote:

UW> Renyi Xiong wrote:
UW> >
UW> > 1. what happens if one of (not all of) the RAM replicas of
UW> > Mnesia table fails when doing write operation? write fails?
UW>
UW> If you are using transactions, chances are good that mnesia
UW> will be able to follow through after all. The transaction
UW> is completed as an 'asymmetric' transaction, and the failed
UW> node gets the opportunity to update itself later.

Yes, the transaction is completed consistently on the
surviving nodes. On the node(s) where Mnesia fails to
write, Mnesia will be terminated. When Mnesia later is
started on these nodes, it will pick the table contents
from the surviving node(s). This fundamental behavior
is the same for all types of transactions as well as
for dirty writes.

For transactions using 3pc, the recovery procedure is
more complicated as the failing nodes may need to
determine the outcome of the transaction before the
transaction log can be processed. 3pc is used for
transactions involving updates of the schema or
asymmetrically replicated tables.

UW> (Of course, assuming that the failed node is not the
UW> one  that initiated the transaction.)

The recovery procedure is the same, even if it was the
failing node that initiated the transaction.

UW> If you're using dirty writes, you may end up with
UW> database inconsistency. Don't use dirty writes on
UW> replicated tables unless you really really know what
UW> you're doing.

This is a good general advice.

Using dirty writes on replicated tables, is about as
hazardous as using master nodes, using the
max_wait_for_decision configuration parameter or to
force load tables. Elaborating with these mechanisms
may easily end up with an inconsistent database as
they bypasses the transaction recovery procedure in
Mnesia. Sometime it is necessary to use these
mechanisms, but use them with care.

/Håkan

UW> > 2. Is Mnesia table RAM replica distributable across VPN network?
UW>
UW> If you can get Distributed Erlang to work, you will be able to
UW> replicate mnesia tables. Without Distributed Erlang - no replication.
UW>
UW>
UW> > 3. Is possible to add and remove RAM replica dynamically?
UW>
UW> Yes, using the function
UW>
UW>   mnesia:add_table_copy(Tab, Node, Type)
UW>
UW> where Type == ram_copies, if it's a RAM replica you want to add.
UW>
UW> Removing a replica:
UW>
UW>   mnesia:del_table_copy(Tab, Node)
UW>
UW> Regards,
UW> Ulf W