Re: Lock-free databases
Date: Sat, 05 Nov 2005 02:48:40 GMT
Message-ID: <c4Vaf.406111$1i.307864_at_pd7tw2no>
> "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
> ...
I'm not a concurrency expert but I've seen lots of places where I didn't need the low-level (eg. row level) locking that happened under the covers (not to mention physical locking that physical access servers do to avoid their own internal deadlocks as well as handle their checkpoints and such).
Usually it was because we knew more about the application than the engine ever could, eg certain tables were never updated except offline and so forth (mostly i was dealing with strict 2 phase lock protocols which are about as strict as they come) or the internal locks got in the way of different users updating at the same time, when the application's nature was such that those users could never clash at a logical level.
Sometimes I'd use the lock manager to bend things - eg. use a parent transaction to get an intent lock on a row in an application table whose only purpose was to get locks, so that an independent child transaction could be guaranteed to do what it wanted without collisions - the parent would rollback its intents when the child completed (we didn't have select-for-update and this proved you could get the same effect without locks at least at the application level).
I'm curious whether any current products (I'm years out of touch) actually implement real predicate locks (such as described by Gray).
pc Received on Sat Nov 05 2005 - 03:48:40 CET