Re: ACID et al

Daniel Dittmar wrote:
> paul c wrote:
>

>> 3) Assume the engine is single-threaded. Two users' messages can't 
>> interleave their actions between each other, ie., messages are 
>> 'single-file'.

Fair enough assuming you mean 'lock' in the most general or abstract sense as opposed to what a person responsible for maintaining the code of a conventional 'lock manager' would call a lock. I wouldn't argue if you said I was talking about a design that was 'lock-manager-less', ie., the *absence* of a component giving the effect we want, namely ACID. In other words the question for me is not whether we can have a system without locks, but whether we can avoid a lock-manager and still have ACID.

>

>> 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.

>> with customer and or balance rows).  The second updating message 
>> (which might occur many minutes or hours after the first) might 
>> reiterate the original queries in some form, perhaps including certain 
>> data such as 'balance = $500' which would be asserted to still be true 
>> before the debit is made persistent.

Again, I was using 'lock' in the very specific physical sense. As for 'optimistic', I won't nit-pick that either except to say that what I've noticed over a long time, is what I think of as really high-performance applications inevitably had to invent their own locking protocol because the underlying system's protocols were too general for their specific purpose and concurrency demands. Usually, the specific solutions were very simple and easier for developers to understand than general concurrency theory!

p Received on Mon Dec 05 2005 - 17:34:19 CET