Leyne, Sean wrote:

>>> Jim,
>>>
>>> You are probably aware of them already, but the folks at sprout-
>>> clustrix (US based start-up, few $ mln funding) seem to be working
>>>
> on
>
>>> the very ideas being discussed in this list.
>>>
>>> www.startuply.com/Jobs/Core_Software_Development_Engineer_115_1.aspx
>>>
>>>
>> I don't think so. A distributed lock manager is definitely the wrong
>> way to go. Little clusters, sure, but anything synchronous is going
>>
> to
>
>> be a problem in an open ended cloud.
>>
>
> Why is that, Jim?
>
>

Locking protocols require that you wait for a lock before you can do
anything. A distributed lock manager, in turn, must request and wait
for the lock from whatever node is managing that part of the lock tree.
This adds a round trip to each primitive operation. Or two, rather,
because the lock must also be released, though I suppose that can be
done asynchronously.

I don't think a system based on exclusive access to portions of the data
is anywhere near the right solution. Algorithms that can execute in
parallel are a great deal more interesting. Multi-generational
concurrency control, for example, does not depend on locks or strict
serialization of access to objects. Constraints do require special
handling to preserve uniqueness and prevent two concurrent transactions
from updating a single record, but neither of these requires the latency
inducing overhead of a lock manager.

I think the biggest obstacle to a cloud-based database is getting over
the hangups of traditional database implementations and accepting the
quite different trade-offs inherent in a cloud. A central lock manager
certainly suggests the mindset that a cloud is just a big SMP system.
It isn't.