Re: computational model of transactions

I see your point. Check the example I proposed and you see the danger in the approach...

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.
>
> p
Received on Tue Aug 01 2006 - 21:46:53 CEST