Re: Lock-free databases

"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 ?

> 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".

>
> In the case of an in memory database, you could put the database
> in to a read only shared segment and allow processes running on
> the same machine to run queries directly against the memory without
> any IPC or communication overhead. No syscalls essentially.
>
> And if there's any benefit to making a database lock-free, would
> there be a particular type of database that would benefit the most?
> Or is lock-free only suitable as a marketing term?

You might benefit from readin a book on concurency control, for example, Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman: Concurrency Control and Recovery in Database Systems, 1987.

>
>
> --
> Joe Seigh
>
> When you get lemons, you make lemonade.
> When you get hardware, you make software.
Received on Fri Nov 04 2005 - 12:52:56 CET