Re: ACID et al

From: Daniel Dittmar <daniel_at_dittmar.net>
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!

Concurrency issues are notoriously difficult to get right. Implementing a special solution is therefor the high risk option and simply not worth it for most requirements.

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

Putting the synchronization into the db engine provides at least a lowest common denominator for your applications. And in business, reliability is often valued above performance.

(I would actually say that most home grown concurrency orchestrations are both less reliable and slower than the general solution, especially when the applications change over time)

Daniel Received on Tue Dec 06 2005 - 00:13:04 CET

Original text of this message