Re: computational model of transactions
- From: paul c <toledobythesea@xxxxxxxx>
- Date: Tue, 01 Aug 2006 18:54:47 GMT
Cimode wrote:
paul c wrote:paul c wrote:Hi paul...;)Marshall wrote:Oops, bad choice of words. Should have said "for its results". Doesn'tI've been thinking about concurrency and transactions. It occurs to meThat is the concurrency problem, two cooks in the kitchen. I believe
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".
the term 'transaction' was coined to give a program context for its
updates, ...
have to be only updates.
p
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
.
- Follow-Ups:
- Re: computational model of transactions
- From: Cimode
- Re: computational model of transactions
- From: Bob Badour
- Re: computational model of transactions
- References:
- computational model of transactions
- From: Marshall
- Re: computational model of transactions
- From: paul c
- Re: computational model of transactions
- From: paul c
- Re: computational model of transactions
- From: Cimode
- computational model of transactions
- Prev by Date: Re: computational model of transactions
- Next by Date: Re: The Database that Understands What It's Told
- Previous by thread: Re: computational model of transactions
- Next by thread: Re: computational model of transactions
- Index(es):
Relevant Pages
|
Loading