Re: computational model of transactions
- From: Bob Badour <bbadour@xxxxxxxxxxxxxxxx>
- Date: Tue, 01 Aug 2006 19:42:13 GMT
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.
Marshall's proposal is more severe than serializable. A user would not see his own updates to the database until after committed. With the serializable isolation level, one still sees prior updates within the transaction.
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.
.
- Follow-Ups:
- Re: computational model of transactions
- From: paul c
- Re: computational model of transactions
- From: paul c
- 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
- Re: computational model of transactions
- From: paul c
- computational model of transactions
- Prev by Date: Re: Surrogate Keys: an Implementation Issue
- Next by Date: Re: computational model of transactions
- Previous by thread: Re: computational model of transactions
- Next by thread: Re: computational model of transactions
- Index(es):
Relevant Pages
|