Re: ACID et al

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:fljlf.57085$Eq5.50047_at_pd7tw1no...

> I used to ridicule the OS developers for their short-sightedness.
> (Haven't changed my mind - the only reason I stopped complaining is that
> it's a waste of time.) In the 1980's and early 1990's (I don't know
> about now) I followed fairly closely what the db engine developers for
> various products were doing. One thing they were doing was spending a
> lot of time extending existing OS facilities such as locking to the db
> environment. Another thing was writing low-level disk drivers. The
> list was a long one. The OS manuals would describe api's to use various
> OS services but they were always insufficient for the db's. I found
> this so ironic since when it came to concurrency, both camps were
> working really on the same problem. And both camps were of the 'not
> invented here' persuasion. For me, the problem goes deeper, right down
> to cpu architecture. Trade press thought it was great when
> stack-oriented processors became common. Even IBM acceded with their
> mainframes. But I heard nobody ask the HW people, where's the
> double-ended stack that makes language interpretation so much easier.
> So all the compiler/interpreter people had to write their own in software.

I don't want to hijack the thread, more than I have already, but I can't resist throwing in two cents here.

I disagree. But my view is heavily influenced by DEC VMS and DEC Rdb. The DEC VMS lock manager was integral to the OS, and very comprehensive. DEC Rdb was able to use a subset of the lock manager services for its own purposes. I don't think either engineering group was shortsighted, compared to most. Received on Wed Dec 07 2005 - 15:38:23 CET