Re: Indexes and Logical design

From: David Cressey <david.cressey_at_earthlink.net>
Date: Mon, 12 Sep 2005 13:41:53 GMT
Message-ID: <BAfVe.11258$FW1.10658_at_newsread3.news.atl.earthlink.net>


"Christopher Browne" <cbbrowne_at_acm.org> wrote in message news:QYdVe.1083$1G4.145462_at_news20.bellglobal.com...

> Pretty well any of the database systems still undergoing active
> development offer some variation of MultiVersion Concurrency Control
> (MVCC) where updates lead to creating new versions of tuples, which
> allows the reads, at least, to not require any locks...

I'm not sure, but I think the Rdb/VMS "snapshot transaction" qualifies as "some variation on MVCC".

In an Rdb database, read only transactions can be either locking or snapshot, depending on DBA decisions.

In the case of snaphot transactions, commited updates do indeed cause the retention of before images of tuples
(and of index nodes as well, by the way), but no row locking is needed to guarantee consistency for the snapshot transaction. A snapshot transaction could last for hours, while locking transactions proceed forward unhindered (expect for the extra overhead caused by retaining before images).

Rdb/Eln used MVCC as its concurrency management tool, as VC said, and that's very different from Rdb/VMS. I briefly used a sub rosa version of "Rdb/Eln running on VMS" that was released internally in DEC a few months before Rdb/VMS. I don't know Interbase, but a quick look at its metadata organization strongly suggests that it was Rdb/Eln all over again. And the role that Starkey played also suggests the same thing. Received on Mon Sep 12 2005 - 15:41:53 CEST

Original text of this message