[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Vrs-development] Repost (two phase commit protocol intro)
From: |
Eric Altendorf |
Subject: |
[Vrs-development] Repost (two phase commit protocol intro) |
Date: |
Sun, 14 Jul 2002 13:47:59 -0700 |
User-agent: |
KMail/1.4.1 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Vrs-development] Repost (two phase commit protocol intro),
Eric Altendorf <=