Home -> Usenet -> comp.databases.theory -> Re: computational model of transactions

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_at_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 - 20:54:47 CEST












Original text of this message