Re: Indexes and Logical design
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