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