[Vrs-development] Repost (two phase commit protocol intro)

[Eric Altendorf]

someone requested a intro/refresher on TPC ... see the URL below; it's 
a very good concise explanation with diagrams.

----------  Forwarded Message  ----------

Subject: Re: [Vrs-development] IBM Token Ring Thingy...
Date: Fri, 3 May 2002 16:56:17 -0700
From: Eric Altendorf <address@hidden>
To: Bill Lance <address@hidden>, address@hidden, 
address@hidden

On Friday 03 May 2002 16:04, Bill Lance wrote:
> I agree that transactions are the way to go.  However,
> a two phase commit is a problem, if you mean the
> second phase as a verification step.  There is no
> process that we can afford to hold pending
> verification.  We might run a background monitor
> tracing all transaction results, but if we design this
> right, that shouldn't be necessary.  And it would
> certainly incresase the overhead significantly.

You can't have distributed transactions without a two phase commit...
 and you can't have consistency without transactions.

For a definition of 2PC, see:
http://www.vermicelli.pasta.cs.uit.no/ipv6/students/andrer/doc/html/n
ode18.html

This is the point I've been trying to make about the distributed
 filesystem. For example, there is no way to guarantee that nodes
 don't store conflicting versions of files without forcing the
 coordinator to, upon every write request, contact every LDS node
 which stores the block in question, ask it to postpone reads of that
 block, ask it to write the new data, and then either: (1) wait to
 receive a success message from every node, then send out a second
 message saying the write is complete, and the system can continue,
 or (2) timing out or getting a failure reply from an LDS node, in
 which case the coordinator must send out an abort message and every
 LDS node must undo the write.

This is why these sorts of systems are so complex and hard to write. 
 This is what keeps Oracle in business. :-)

> We are trying to maintain an organic looseness between
> the LDS elements.

I understand the drive to do this, but to acheive full "looseness"
 you'll have to accept the possibility of inconsistent data in
 whatever you're talking about (e.g., the cluster image, or the data
 on the distributed filesystem).

The question is whether we need to guarantee consistency or not.  It
 sounds like for the cluster image, we may not need to guarantee
 consistency.  For the filesystem, I think we probably do.

Eric

--
"First they ignore you.  Then they laugh at you.
 Then they fight you.  And then you win."             -Gandhi

_______________________________________________
Vrs-development mailing list
address@hidden
http://mail.freesoftware.fsf.org/mailman/listinfo/vrs-development

-------------------------------------------------------

-- 
"First they ignore you.  Then they laugh at you.
 Then they fight you.  And then you win."             -Gandhi