Re: Lock-free databases


"Mark D Powell" <Mark.Powell@xxxxxxx> wrote in message
news:1131377410.830202.214120@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Even for read only access where multiversioning with timestamp ordering
> exists (basically what Oracle uses) access to the block where the
> consistent view of the data is built has to be restricted. In Oracle's
> case latches would be used.
>
> Remember that any single threading mechanism no matter if you call it a
> lock, latch, enqueue, or other name is a lock for the purpose of this
> discussion which is about "lock free" database products.

I am afraid you are confused at least on two counts.

1. Database concurrency control. When one talks about concurrency control,
one assumes atomic reads and writes (in order to make concurrency
treatement manageable). How a specific product, be it Oracle or SQL Server
or something else, chooses to protect its internal memory structures in
order to emulate atomic reads is an irrelevant implementation feature.
What's relevant is the user level of abstraction, how a data item(row) is
handled to ensure data integrity. In Oracle, to describe concurrency one
would say that there is only the write lock (TX) and no read locks
(forgetting for a moment about various DLL and table locks), that's what's
the user sees and uses to implement concurrent transactions efficiently.

By the way Oracle is not MVTSO. Since it has the TX lock, it's a mongrel,
multiversioning plus write locking (as is Postgres or Interbase). There are
other non-locking database concurency control mechanisms, such as different
kinds of SGT (serialization graph testing), Basic TSO, etc. For details,
see the Bernstein book I mentioned earlier.

2. It's possible to implement lock-free data structures such as lists,
hashes, etc (I believe Joe Seigh mentioned that). So, hypothetically,
it's possible to get rid of latches, enqueues, etc. even at the various
memory structures implementation level, be it data cache handling or
library cache management. You might want to google for MCAS or STM to find
ample literature on the subject.

Since the OP was interested in memory resident databases, (2) maybe quite
relevant. Also, it might be intersting to know that Java 5 offers some
tools to implement lock-free concurrent algorithms.




> I say it is
> not really possible.

Well, not true.

>
> HTH -- Mark D Powell --
>


.

Relevant Pages

  • Re: Informix beats Oracle
    ... What's the difference between that and this new feature? ... similar to the Oracle implementation, and was not available in other products. ... Using this, you won't block when trying to read a row that has a lock. ... I'm "tired" of explaining the locking issues to developers that were trained only in Oracle... ...
    (comp.databases.informix)
  • Re: Deadlock - advice needed
    ... Lock table order_release_bp in share mode; ... Resource Name process session holds waits process session holds waits ... After reading about the Oracle locking, my guess is the the stored ... "Unindexed foreign keys cause DML on the primary key to get a share row ...
    (comp.databases.oracle.server)
  • Re: Locking question when using Select clause with For Update and Skip locked
    ... This is working fine in SQL Server and multiple session can get the ... But in Oracle the first session only return 1 row but locks all the ... It looks like both the session got the ROW-X lock but one session is ...
    (comp.databases.oracle.server)
  • Re: How to update multiple rows atomically
    ... I don't want to lock just one up, ... be subject to deadlock or starvation? ... Whether it might experience deadlock or starvation or any other concurrency problem will depend on what concurrency mechanisms the dbms implements, which concurrency options the dba and various users choose, and how the dbms implements them. ...
    (comp.databases.theory)
  • about concurrency (again)
    ... I have been reading the recent thread about concurrency, ... def disable_safe_mode: ... # "instantiate" the manager in the main thread ... the lock could be a file lock or a transactional lock. ...
    (comp.lang.functional)