Re: computational model of transactions

From: paul c <toledobythesea_at_oohay.ac>
Date: Tue, 01 Aug 2006 18:54:47 GMT
Message-ID: <XrNzg.299468$iF6.183642@pd7tw2no>

Cimode wrote:
> paul c wrote:

>> paul c wrote:
>>> Marshall wrote:
>>>> I've been thinking about concurrency and transactions. It occurs to me
>>>> that much of the difficulty lies with the fact that multiple concurrent
>>>> transactions may operate on the same data. I begin to recall some
>>>> conversations from years past about "multiple assignment".
>>> That is the concurrency problem, two cooks in the kitchen.  I believe
>>> the term 'transaction' was coined to give a program context for its
>>> updates, ...
>> Oops, bad choice of words.  Should have said "for its results".  Doesn't
>> have to be only updates.
>>
>> p

> Hi paul...;)
>
> Unfortunately, concurrency is not the only issue here...The real
> underlying issue here is finding a computational model that does not
> jeopardize data integrity on RM standpoint and preserves data
> independence between logical and physical layer...It is a very complex
> problem that can not be dealt with simplyistic SQL based solutions. I
> doubt that any SQL DBMS will be able to deal with it efficiently...not
> now, not in a thousand years...
>

I mentioned SQL only to illustrate because it seems that so many people are familiar with it (or think they are). Lock managers aren't unique to SQL products. Having said that, I think the SQL people hit on the right word with "SERIALIZABLE", assuming we would like a database to have a single value at a point in time. Rather than 'computational model', I think Marshall S is really talking about a 'serializable model', to try to put it exactly.

p Received on Tue Aug 01 2006 - 13:54:47 CDT