[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Vrs-development] IBM Token Ring Thingy...
From: |
Eric Altendorf |
Subject: |
Re: [Vrs-development] IBM Token Ring Thingy... |
Date: |
Fri, 3 May 2002 16:56:17 -0700 |
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/node18.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