Re: ACID et al

Daniel Dittmar wrote:
> paul c wrote:
>

>> ...

No locks outside of the system (other than whatever the OS or some web server chooses to do of its own accord).

  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.

Up to a point, I think they aren't incompatible. Basically, the limits on scaleability that I'm envisaging are three: 1) application memory space (non-paging space), 2) cpu speed, 3) IO bandwidth to write redo records, usually very very short ones and synch them. I'm ignoring start-up time which might involve applying redo records. For many applications I've seen, I think hundreds of small transactions per second are possible on a fairly routine 32-bit PC, given the right kind of disk hw/filesystem and certainly dozens of quite complex ones. The memory limit would imply databases of up to several million rows regardless of the number of tables. Another aspect of scaleability that was prompted by reading about the TRM is to do a four-way join in twice (or less) the time as a two-way join. I'd expect the time for a join on two one-million row tables that produced a result, say, of 100 rows to take roughly the same amount of time as the same join on two ten-thousand row tables. The fact that except for the actual application database tables and the disk-based redolog the system would be 'stateless' in the same sense as ordinary http is what would make the physical limits the operative limits.

Beyond that point are the bigger applications and databases, but I think although they are individually bigger, they are actually a smaller 'market'!

>

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

I'd say the shops I've seen (admittedly tending toward larger ones, even though they were often writing rather small apps!) understood concurrent users very well. I'd agree with you that even some really big shops don't understand concurrent transactions very well. They won't have that problem if the system doesn't allow concurrent 'transactions'!

Not accusing you of touting SQL, but what I remember of 'isolation' levels is an example of the system relinguishing control and I certainly wouldn't advocate that. I'd tell the average unsophisticated installation to go with the defaults, namely forcing what I've been calling 'dynamic constraints', ie. assertions that re-iterate all the 'queries' from a particular user's most recent message. Same as they'd choose some default user authorization scheme which would amount to pre-pending some validation code to each message. This would be in the same language used for the db engine api and would be effected at server start-up, not in the clients. It may all sound like a lot of redundant work, but for the right apps of which I think there are many that would qualify, I don't think that's so.

thanks,
p Received on Tue Dec 06 2005 - 00:55:32 CET