Re: [Vrs-development] IBM Token Ring Thingy...

[Eric Altendorf]

On Friday 03 May 2002 07:20, Chris Smith wrote:
> Yep, but you've still got the problem of two or more LDS's broadcasting the
> 'claim cluster image' to the cluster.  You can't have more than one
> claiming the cluster image, so this should fail.  However, it's really
> difficult to engineer because you've got to detect that all nodes in the
> cluster accepted the SAME claim message from the same LDS.  This is hard
> enough, without the added complication that you may not know about all
> LDS's in the cluster.
>
> This is why the MA approach may help.  Each LDS maintains it's own view of
> the cluster image, and is kept in sync as best as possible.  It doesn't
> have to be immediate (and I think we should design with this in mind)
> because we have to deal with the case of LDS's going offline and coming
> back.  Thus the MA idea allows all scenarios to be dealt with.  If an LDS
> comes back on line, then a lot might have changed, and the MA 'data tree'
> will return a wealth of information.

OK, I'm starting to see the picture here with the MA.

I think what it boils down to is that if we have no requirement for the 
cluster images to remain consistent among machines, then there are a number 
of different mechanisms we could use.

If we want to guarantee that the CI remains consistent, or remains "at most X 
minutes out of date" or anything else, I think we're going to have to resort 
to transactions.  Pretty much ANY time we want to make a guarantee about data 
consistency across a distributed network, we're going to have to use 
distributed transactions with two phase commit.

By the way -- I would strongly recommend that anyone working on this project 
go to a library and read *Transaction Processing: Concepts and Techniques" by 
Jim Gray and Andreas Reuter.  There are other books, but that's pretty much 
the bible, AFAIK.

Eric

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