Re: ACID et al

From: paul c <toledobythesea_at_oohay.ac>
Date: Mon, 05 Dec 2005 18:32:26 GMT
Message-ID: <_I%kf.53256$Eq5.23787_at_pd7tw1no>


Daniel Dittmar wrote:
> paul c wrote:
>

>> Daniel Dittmar wrote:
>>
>>> 

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

I suppose the engine I'm imagining could be started up twice by mistake, both times telling it to use the same memory and starting data files and one could thus argue that the engine should obtain some kind of memory lock to prevent this. However, I'd expect that various configuration angles would prevent it in advance, such as inability for two different processes to open the redolog for writing. So there's another lock at the system file or disk manager level. But my argument would remain that that lock isn't implemented by the db engine. I certainly wasn't claiming that one can write a multi-user operating system without locks.   But I'm not proposing to do that! ;)

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

well, i think one general principle is that general principles are often too general in practice. another one is that i think it's a fallacy to imagine (not that i'm saying anybody here is) that one can write an app for concurrent users, let alone concurrent transactions without thinking through how their different purposes might clash, no matter how well the db engine in question is marketed!

Thanks - this is helping me with my lingo - i should be talking about concurrent users, not concurrent transactions (just in case i used the latter term anywhere).

p Received on Mon Dec 05 2005 - 19:32:26 CET

Original text of this message