Re: computational model of transactions
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 01 Aug 2006 19:42:13 GMT
Message-ID: <p8Ozg.31840$pu3.424447_at_ursa-nb00s0.nbnet.nb.ca>
>
> 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.
Date: Tue, 01 Aug 2006 19:42:13 GMT
Message-ID: <p8Ozg.31840$pu3.424447_at_ursa-nb00s0.nbnet.nb.ca>
paul c wrote:
> 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.
What if one combines multiple logical units of work into a single transaction? I have seen this done for performance in batch processes to faciliate effective physical buffering etc. With Marshall's proposal, this would not be possble. Received on Tue Aug 01 2006 - 21:42:13 CEST