Re: Lock-free databases

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

There are "lock free data structure algorithms," which might get used in a database engine; this wouldn't eliminate locks at higher levels within the database implementation.

Consider: If two connected users are simultaneously trying to update the same row (say, adding to/subtracting from an account balance), there *must* be some mechanism to keep those updates from trampling on one another. Eliminating locks in the storage engine doesn't eliminate the need for something like locking there.

I am generally a PostgreSQL user; it has eliminated *most* need for read locks by virtue of keeping old copies of rows around (e.g. - MVCC), but that comes at *some* cost (need to VACUUM), and must _not_ be mistaken for a total elimination of locking.

Pretending to eliminate locking seems likely to me to be more marketing than reality.

Mind you, I'm coming from something of an OLTP perspective; it's *possible* that OLAP systems that only see mass updates might see some benefit from non-locking approaches...

-- 
(reverse (concatenate 'string "moc.liamg" "_at_" "enworbbc"))
http://cbbrowne.com/info/
If we were meant to fly, we wouldn't keep losing our luggage.