Re: computational model of transactions
- From: "Erwin" <e.smout@xxxxxxxxxxx>
- Date: 4 Aug 2006 04:10:17 -0700
It is not always the case that if more than one actor is
updating the same resource, that those updates must be serialized.
I leave that one on your account.
To illustrate this, ignore the business rules in the above example.
Ignoring business rules is not my idea of a good example. And
especially not this kind of example, since I've been a bank programmer
for 15 years. I can assure you no one in the bank business would
accept the kind of risky manipulations with account balances that you
propose.
The semantics of the update involve modification, not replacement
You obviously see a difference between modification and replacement. I
don't. So please explain.
the operation
involved, addition, is communitive and associative.
You mean "commuTAtive", of course, and furthermore that's completely
irrelevant. As for associativity : it is important to observe that
each transaction in this example does exactly one addition with exactly
two arguments. So unless you can think of a way for the system to
detect that multiple independent transactions are doing such a thing
(performing an associative operation), and then replace those multiple
independent operations with one single, transaction-surpassing,
operation that has the same result, associativity is also irrelevant.
If you cannot think of such a way for the system to detect this (I'm in
that case), you're stuck with doing multiple additions one-at-a-time,
and you're stuck with the fact that for the additions that are executed
second and third, one of those arguments should be the result of the
former. Therefore it is necessary that the transactions be serialized.
Otherwise it would mean a transaction is allowed to see uncommitted
results from another one.
.
- Follow-Ups:
- Re: computational model of transactions
- From: Brian Selzer
- Re: computational model of transactions
- From: JOG
- Re: computational model of transactions
- References:
- computational model of transactions
- From: Marshall
- Re: computational model of transactions
- From: Brian Selzer
- Re: computational model of transactions
- From: vc
- Re: computational model of transactions
- From: Brian Selzer
- Re: computational model of transactions
- From: Erwin
- Re: computational model of transactions
- From: Brian Selzer
- computational model of transactions
- Prev by Date: Re: why hierarchy?
- Next by Date: Re: VAT rate or VAT amount as a column?
- Previous by thread: Re: computational model of transactions
- Next by thread: Re: computational model of transactions
- Index(es):
Relevant Pages
|