Re: ACID et al
Date: Tue, 06 Dec 2005 00:13:04 +0100
Message-ID: <3vjvr1F14pcgqU1_at_uni-berlin.de>
paul c wrote:
> 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! ;)
It sounds to me as if you want to *require* locks outside of your system while still claiming to be lockless. Which I would call cheating. But then I haven't actually understood if your aiming for minimal complexity or maximal scalability. Your posts seem to indicate both at the same time.
> 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!
Daniel Received on Tue Dec 06 2005 - 00:13:04 CET