Re: computational model of transactions
- From: "Brian Selzer" <brian@xxxxxxxxxxxxxxxxxxx>
- Date: Fri, 04 Aug 2006 09:17:23 GMT
"Erwin" <e.smout@xxxxxxxxxxx> wrote in message
news:1154677918.807478.221990@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Let's say that you're account starts out with a balance of $550.
At time T1 a transaction is started to post a check for $500.
At time T2 a transaction is started to post a check for $100.
At time T3 a transaction is started to post a check for $75.
At time T4 the $100 transaction completes, recording a balance of $450.
At time T5 the $75 transaction completes, recording a balance of $375.
At time T6 the $500 transaction completes, recording a balance of $-125.
The error is that these transactions are "allowed to run concurrently".
Since each of them wants to update the very same resource (the same
attribute of the same tuple of the same relvar), these transactions
should be serialized anyway.
I disagree. It is not always the case that if more than one actor is
updating the same resource, that those updates must be serialized. To
illustrate this, ignore the business rules in the above example. The
semantics of the update involve modification, not replacement, the operation
involved, addition, is communitive and associative, and all of the updates
in question have the same semantics; therefore, it is only important that
the modifications be either disjoint or aggregated, but not necessarily
serialized: the order in which the modifications occur is not important,
since the end result is the same. In addition, only the operation on the
shared resource need be disjoint, other operations involving other resources
within each transaction can occur simultaneously, so serializing each entire
transaction would be overkill.
No two things can be in the same place at the same time.
.
- Follow-Ups:
- Re: computational model of transactions
- From: Marshall
- Re: computational model of transactions
- From: Erwin
- 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
- computational model of transactions
- Prev by Date: Re: computational model of transactions
- Next by Date: Re: why hierarchy?
- Previous by thread: Re: computational model of transactions
- Next by thread: Re: computational model of transactions
- Index(es):
Relevant Pages
|