Subject Re: [Firebird-Architect] Special Relativity and the Problem of Data Scalability, Take 2
Author Paul Ruizendaal
On Fri, 19 Mar 2010 15:45:41 -0400, Jim Starkey <jstarkey@...>
wrote:
> Jim Starkey wrote:
>> Here are the slides from my IEEE/ACM talk last night. We've talked
>> about much of this stuff before, but here it is in a single place.
>>
>>
> http://www.nimbusdb.com/SpecialRelativity.pdf

Thanks for providing the summary. I hope your audience was on board the
clue train and that a lively discussion ensued.

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?

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?

On page 32 you have a line about network partitions: "the partition that
contains a coterie survives". If you mean by that that only one partition
can survive, such places restrictions on how "coteries" are formed. If
multiple survivors are allowed, how do you propose to handle reconnection
of two or more partitions? Note that on a heavily loaded system, messages
may time out leading a system to think there are intermittent network
partitions.

By the way, wouldn't it be clearer if you named "coteries" something like
"commit agent groups", or "commit agent clusters", or perhaps "commit
groups" or "commit clusters" for short? Perhaps "objects" in place of
"atoms"? Perhaps "active node set" or "active partition" instead of
"chorus"?

Regards,

Paul