Home -> Usenet -> comp.databases.theory -> Re: ACID et al

Re: ACID et al

From: Daniel Dittmar <daniel.dittmar_at_sap.corp>
Date: Mon, 05 Dec 2005 18:30:07 +0100
Message-ID: <dn1tf0$h45$1_at_news.sap-ag.de> 






paul c wrote:


> 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'.
>>
>> This looks like a lock to me. A rather coarse-grained one.




> 

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




I'd say that if the 'system' must ascertain 3), then some kind of lock 
manager is needed. But maybe I'm using 'system' in the most general and 
abstract sense ;-)



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




But are there any general principles to be learned from these specific 
solutions?



And I'm not saying there isn't, as most synchronization methods used 
today are probably generalizations of lessons learned the hard way.



Daniel
Received on Mon Dec 05 2005 - 18:30:07 CET












Original text of this message