mnesia question

[Renyi Xiong]

what if one node participant fails to respond (machine down or network down) 
during commit process while the coordinator waiting for commit vote 
('receive' waits forever for a message, right?)

the reason why I'm asking this question is that:

our system is designed to handle thousands of write transactions a second 
and to have multiple replicas to provide fault tolerance. if one replica 
down and fails to send 'mnesia_down' message. there is a good chance that a 
commit process is on going.

does 'mnesia_monitor' on coordinator node handle that?

Thanks,
Renyi.

----- Original Message ----- 
From: "Hakan Mattsson" <hakan@REDACTED>
To: "Renyi Xiong" <rxiong@REDACTED>
Cc: "Ulf Wiger (AL/EAB)" <ulf.wiger@REDACTED>; 
<erlang-questions@REDACTED>
Sent: Tuesday, February 14, 2006 2:04 AM
Subject: Re: mnesia question


On Wed, 8 Aug 2001, Renyi Xiong wrote:

RX> Thanks guys,
RX> It's really helpful for us to understand how Mnesia works.
RX>
RX> 1.My understanding is when one node initiates a write operation it sends 
a
RX> message to each of the replicas at same time and doesn't care the write
RX> transaction status on other replicas. It's up to the transaction handler 
on
RX> each node to handle the write transaction separately. Is that right?

Yes, this is true for normal transactions using
2pc. But it is not as bad as it sounds as the
transaction recovery protocol ensures that the
outcome of the transaction always is atomic.

If needed, Mnesia will automatically use 3pc as
transaction protocol. It is slower, but takes
care of transactions operating on multiple tables
which are replicated asymmetrically.

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

Use mnesia:sync_transaction/1. It waits for all
participating nodes to complete their commit work
before it returns. It is slower, but needed in
some applications.

/Håkan

RX> Thanks,
RX> Renyi.
RX>
RX> ----- Original Message ----- From: "Hakan Mattsson" 
<hakan@REDACTED>
RX> To: "Ulf Wiger (AL/EAB)" <ulf.wiger@REDACTED>
RX> Cc: "Renyi Xiong" <renyix1@REDACTED>; <erlang-questions@REDACTED>;
RX> <rxiong@REDACTED>
RX> Sent: Monday, February 13, 2006 8:54 AM
RX> Subject: RE: mnesia question
RX>
RX>
RX> On Mon, 13 Feb 2006, Ulf Wiger (AL/EAB) wrote:
RX>
RX> UW> Renyi Xiong wrote:
RX> UW> >
RX> UW> > 1. what happens if one of (not all of) the RAM replicas of
RX> UW> > Mnesia table fails when doing write operation? write fails?
RX> UW>
RX> UW> If you are using transactions, chances are good that mnesia
RX> UW> will be able to follow through after all. The transaction
RX> UW> is completed as an 'asymmetric' transaction, and the failed
RX> UW> node gets the opportunity to update itself later.
RX>
RX> Yes, the transaction is completed consistently on the
RX> surviving nodes. On the node(s) where Mnesia fails to
RX> write, Mnesia will be terminated. When Mnesia later is
RX> started on these nodes, it will pick the table contents
RX> from the surviving node(s). This fundamental behavior
RX> is the same for all types of transactions as well as
RX> for dirty writes.
RX>
RX> For transactions using 3pc, the recovery procedure is
RX> more complicated as the failing nodes may need to
RX> determine the outcome of the transaction before the
RX> transaction log can be processed. 3pc is used for
RX> transactions involving updates of the schema or
RX> asymmetrically replicated tables.
RX>
RX> UW> (Of course, assuming that the failed node is not the
RX> UW> one  that initiated the transaction.)
RX>
RX> The recovery procedure is the same, even if it was the
RX> failing node that initiated the transaction.
RX>
RX> UW> If you're using dirty writes, you may end up with
RX> UW> database inconsistency. Don't use dirty writes on
RX> UW> replicated tables unless you really really know what
RX> UW> you're doing.
RX>
RX> This is a good general advice.
RX>
RX> Using dirty writes on replicated tables, is about as
RX> hazardous as using master nodes, using the
RX> max_wait_for_decision configuration parameter or to
RX> force load tables. Elaborating with these mechanisms
RX> may easily end up with an inconsistent database as
RX> they bypasses the transaction recovery procedure in
RX> Mnesia. Sometime it is necessary to use these
RX> mechanisms, but use them with care.
RX>
RX> /Håkan
RX>
RX> UW> > 2. Is Mnesia table RAM replica distributable across VPN network?
RX> UW>
RX> UW> If you can get Distributed Erlang to work, you will be able to
RX> UW> replicate mnesia tables. Without Distributed Erlang - no 
replication.
RX> UW>
RX> UW>
RX> UW> > 3. Is possible to add and remove RAM replica dynamically?
RX> UW>
RX> UW> Yes, using the function
RX> UW>
RX> UW>   mnesia:add_table_copy(Tab, Node, Type)
RX> UW>
RX> UW> where Type == ram_copies, if it's a RAM replica you want to add.
RX> UW>
RX> UW> Removing a replica:
RX> UW>
RX> UW>   mnesia:del_table_copy(Tab, Node)
RX> UW>
RX> UW> Regards,
RX> UW> Ulf W