Re: ACID et al

vc wrote:
> paul c wrote:
>

>>I'm interested to see any comments the group has on something I'm
>>(haphazardly) working on which in part has to do with guaranteeing the
>>ACID properties without locking.

Yes, another way to say what I meant might be that such an implemention wouldn't support concurrent transactions, only concurrent users!

>
> [...]
>

>>4) Assume that a message to the engine includes all the db actions for
>>some 'business' transaction. These actions might include re-iterated
>>reads of rows that were issued in an earlier 'query' message, as well as
>>possibly the values that were returned earlier, as well as update actions.

>>Consistency by 4).

Perhaps I wasn't clear, but it's clear to me that the assertions in a 'transaction message' would need to be logically "and-ed" with pre-existing 'integrity' constraints.

>
>
> [...]
>

>>Basically, I'm talking about an engine that is good at checking
>>constraints and thus can be stateless as far as conventional locks are
>>concerned, ie., it would have no 'lock manager' component per se.

That sounds encouraging. As for the 'price of fish', I was thinking of the price of code maintenance, system admin and the insidious cost of extraneous concepts, I mean extraneus to the purpose at hand.

All the memory and horsepower that I used to dream of thirty or more years ago seems to get spent on making the traditional code infrastructure bigger rather than availing itself to the apps!

(To further explain my purpose, back then I used to take care an app I loved, which was syndicated reports about chocolate bar sales. It had to be done in seven steps because there was only enough memory to hold the data for one region of the country and then the six regions had to be rolled-up for national reports. I was constantly writing special programs to do custom analysis. Today there is enough memory to fit it all into a spreadsheet, except that Excel or the new OpenOffice limit a sheet to 64K rows. Meanwhile the memory to go beyond that is fairly cheap to buy, but the trend in Excel and OpenOffice is to either add more gew-gaws to the interface or chew up time and storage with slavish homage to XML. Similar complaints about the small-scale db engines such as Jet and why bother with SQL Server with its myriad of arbitrary concepts for a couple of dozen heavy users of a hundred tables or a couple of thousand light users of a dozen tables if it's the case that the majority of applications are not giga/tera-byte enterprise apps? Today I think that all I really needed back then was a minimal but respectful imlementation of the RM and I think this goes for many, many other apps too.)

thanks,
p Received on Mon Dec 05 2005 - 18:01:45 CET