Re: Lock-free databases

From: Christopher Browne <cbbrowne_at_acm.org>
Date: Fri, 04 Nov 2005 10:47:18 -0500
Message-ID: <m3hdas9zzt.fsf_at_mobile.int.cbbrowne.com>


> "Joe Seigh" <jseigh_01_at_xemaps.com> wrote in message
> news:XYSdnV1mD7BmJ_fenZ2dnUVZ_tqdnZ2d_at_comcast.com...
>> Is there any significant benefit to making a database
>> lock-free? By lock-free I mean the internal implementation.
>> I know there's a database out there that frequently claims
>> to be lock-free but I've looked at their "lock-free" patents
>
> What "lock-free" patterns did you look at ?
>
>> and I think most of the benefit in their case is from being
>> an in memory database.
>
> Could you clarify the above ?

In-memory databases can eliminate some of the logic traditional in the traditional "paging oriented" data access methods. One benefit to be expected is that, in an "in-memory" system, the "latency time" for data access is the speed of memory. There is no need to prefer data "in cache" because ALL the data can be accessed in the same uniform time.

None of that mentioned locking, which I imagine was the O.P.'s point...

>> I'm talking about real lock-free, e.g. making the indices lock-free
>> to allow concurrent updates without having to rebuild the indices,
>> or allowing queries to run concurrently with updates.
>
> You may be interested to know that Oracle (or Rdb or Postgres or
> Interbase) do just that, "allow queries to run concurrently with
> updates".

But they do _not_ do this via entirely eliminating locking. They all have extensive infrastructure for lock management.

It's well and good that they try to avoid the problems associated with heavy-handed locking policies, but it is NOT at all the case that they are "lock-free."

-- 
wm(X,Y):-write(X),write('_at_'),write(Y). wm('cbbrowne','acm.org').
http://linuxdatabases.info/info/slony.html
"If you  pick up a starving dog  and make him prosperous,  he will not
bite you; that  is the principal difference between a  dog and a man."
-- Mark Twain
Received on Fri Nov 04 2005 - 16:47:18 CET

Original text of this message