Subject | Re: [Firebird-Architect] Special Relativity and the Problem of Data Scalability, Take 2 |
---|---|
Author | Ann W. Harrison |
Post date | 2010-03-22T21:45:22Z |
Paul Ruizendaal wrote:
keeps a chairmanship succession list and when (not if) the chairman
dies, the next node on the list becomes the chairman. The list should
be the same in all copies of the atom. It's possible that the
chairman will die at an inopportune moment - just between updating
the list and the time everybody gets the updated list. In that case,
there will be a short recess while everybody checks all message until
the truth comes out.
archive node (or nodes) receive the commit message, without anything
having to go to disk.
Ann
>I'm not sure Jim answered the second part of the question. Each atom
> On page 21 you introduce a P2P fused cache (caching "atoms"). What is the
> role of the "atom chairman" and what happens if that goes down?
keeps a chairmanship succession list and when (not if) the chairman
dies, the next node on the list becomes the chairman. The list should
be the same in all copies of the atom. It's possible that the
chairman will die at an inopportune moment - just between updating
the list and the time everybody gets the updated list. In that case,
there will be a short recess while everybody checks all message until
the truth comes out.
>Something that may not be clear is that the commit happens when the
> Pages 29 and 32 seem to suggest a variant of 2PC to commit across nodes,
> with the variation being that instead of 2-phase committing between nodes,
> you are 2-phase committing between redundant commit agents ("coteries" in
> your parlance). Is that what you meant?
archive node (or nodes) receive the commit message, without anything
having to go to disk.
>Cheers,
>
Ann