Re: Lock-free databases
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.
-- 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 TwainReceived on Fri Nov 04 2005 - 16:47:18 CET