Re: computational model of transactions

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... Received on Tue Aug 01 2006 - 20:25:40 CEST