Re: ACID et al

From: paul c <toledobythesea_at_oohay.ac>
Date: Mon, 05 Dec 2005 17:14:07 GMT
Message-ID: <zz_kf.47341$ki.41902_at_pd7tw2no>

Daniel Dittmar wrote:
> paul c wrote:
>

>> 3) Assume the engine is single-threaded. Two users' messages can't 
>> interleave their actions between each other, ie., messages are 
>> 'single-file'.

>
>
> This looks like a lock to me. A rather coarse-grained one.

As for coarse-grained, yes, in fact so much so as to be infinitely coarse. However, its duration would usually be measured in milliseconds and it wouldn't need much management since there would never be more one so-called 'lock' in existence!

>

>> 4) Assume that a message to the engine includes all the db actions for 
>> some 'business' transaction. These actions might include re-iterated 
>> reads of rows that were issued in an earlier 'query' message, as well 
>> as possibly the values that were returned earlier, as well as update 
>> actions.

>
> [...]
>

>> with customer and or balance rows).  The second updating message 
>> (which might occur many minutes or hours after the first) might 
>> reiterate the original queries in some form, perhaps including certain 
>> data such as 'balance = $500' which would be asserted to still be true 
>> before the debit is made persistent.

>
>
> This looks like an optimistic lock, with the responsibility of enforcing
> it pushed to the application.

I'd prefer to say 'pushed to the client'. An app with little need for high concurrency could choose to let the messaging layer in the client take care of remembering the previous message, even though that might involve redundant work in the 'server' (only one message would need to be 'remembered', so that kind of infrastructure ought to be fairly simple).

thanks,
p Received on Mon Dec 05 2005 - 18:14:07 CET