Re: ACID et al

From: paul c <toledobythesea_at_oohay.ac>
Date: Tue, 06 Dec 2005 14:52:48 GMT
Message-ID: <4Bhlf.56927$Eq5.13886@pd7tw1no>

x wrote:
> "vc" <boston103_at_hotmail.com> wrote in message
> news:1133867370.295735.64380_at_f14g2000cwb.googlegroups.com...
>

>>Daniel Dittmar wrote:
>>[...]
>>
>>>But the database engines still need row level locking (database engines
>>>using page level locking were not scalable enough). While db locks might
>>>be less relevant in certain parts of the system, they seem to be still
>>>very important in others.
>>>
>>>Daniel
>>
>>Did you read what the OP actually wrote ? He does not need any
>>concurrency control as access to the DB is serial.

>
>
> No. He doesn't said that. He said the access to the DB is concurrent, but
> this doesn't matter because the applications are working correctly anyway
> and is not the bussiness of the DBMS engine to strangle them but to do what
> is asked to and help them if he can.
>
>

Thanks, everybody's comments have been helpful in clarifying the bits and pieces, for me even if nobody else.

I was throwing the word 'concurrency' around too loosely. I think I shouldn't have used it in the first place without defining it more precisely. It might have been better to say there would effectively be *no* concurrency, as far as the db is concerned. Instead of saying 'concurrent users', I should have said everything, as far as the db is concerned, is serial (to use vc's word). The only activity that would be concurrent would be whatever the users are up to outside the db.

1. The serial access to the db seems to take care of the 'I' in 'ACID'.
2. The redolog would take care of the 'D'.
3. The ability for a 'message' to contain multiple db requests would *usually* take care of the 'A' (although any external limits on message sizes might limit this - I need to write a longer note on the implications and see if I can work out a simple scheme, aka "application locking" for the fairly rare occasions when it is needed to do 'batch-style' maintenance as well as notes about security including authorization).
4. A certain amount of redundancy would take care of the 'C'. Default behaviour might be that the client layer would regurgitate some version of the results of a previous message on a subsequent message. It would be as if the server, besides 'reading' and 'writing' would also test assertions. These assertions would effectively be temporary constraints (with 'message' scope if you will), logically 'anded' with permanent constraints including view definitions. But there would be nothing to prevent an app sending additional message-scope constraints. Handling the 'C' well looks like it will be trickier than handling the 'A', 'I' and 'D'.

Also, I should have been more careful using the word 'stateless'. Obviously if the user db is persistent then some 'state' or context is maintained. And depending on the environment (eg. with or without a web server, external message queue layer, etc.) there might need to be a limited 'admin' interface if only to shutdown the db because a naive implementation might leave a window of uncertainty between the synching of the log and the reply to a message (although I believe such uncertainty is already endemic on the www, so maybe it's really a psychological issue).

cheers,
paul c. Received on Tue Dec 06 2005 - 08:52:48 CST