Re: computational model of transactions


"Brian Selzer" <brian@xxxxxxxxxxxxxxxxxxx> wrote in message
news:voHAg.4447$uo6.79@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

"Erwin" <e.smout@xxxxxxxxxxx> wrote in message
news:1154689817.830401.130180@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.


If Rummy says that he's going to increase the troop levels in Baghdad,
that doesn't mean that he's going to replace all of the troops there, just
that additional troops will be sent.

It all comes down to whether the result of the operation depends on the
current value and whether the operation is atomic.

X += 5 is different from X = 10 even if X == 5.

X += 5 translates to something like:
ADD [EBP + 24], 5
which modifies the memory location in place in a single instruction;
whereas X = 10 translates to:
MOV [EBP + 24], 10
which just replaces the value at that memory location.

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.


I really want to address this, but I'm going to be late for work, so I'll
have to address it in a later post.
I'm back. I agree that the updates need to be isolated, but I disagree with
the idea that the entire transaction needs to be isolated or serialized. It
is only necessary to obtain an exclusive lock on the affected row at the
time that the update to the shared resource occurs, so it's possible to have
several other intervening transactions commit between the time that the
transaction starts and the time that the update starts. My point is that it
is not necessary to isolate the entire transaction, only that portion from
the start of the update until the commit. (And it would make a lot of sense
to defer this until the end of the transaction whenever possible.) Nor is
it necessary to serialize, since the update modifies the value that is
current at the time that the update commences, not at the time that the
transaction commences. So there is no danger of seeing uncommitted data
from other transactions. If the effect of an update is a net increase or a
net decrease, then the order in which transactions start is not important:
it is the order in which they complete that determines the state of the
attribute for each corresponding database state. On the other hand, if the
effect of an update is a replacement, then the transactions must be
serialized in their entirety, otherwise you run the risk of losing
information.



.

Relevant Pages

  • Re: computational model of transactions
    ... I leave that one on your account. ... Ignoring business rules is not my idea of a good example. ... operation that has the same result, associativity is also irrelevant. ... Otherwise it would mean a transaction is allowed to see uncommitted ...
    (comp.databases.theory)
  • Re: computational model of transactions
    ... I leave that one on your account. ... Ignoring business rules is not my idea of a good example. ... operation that has the same result, associativity is also irrelevant. ... Otherwise it would mean a transaction is allowed to see uncommitted ...
    (comp.databases.theory)
  • Re: computational model of transactions
    ... I leave that one on your account. ... Ignoring business rules is not my idea of a good example. ... operation that has the same result, associativity is also irrelevant. ... Otherwise it would mean a transaction is allowed to see uncommitted ...
    (comp.databases.theory)
  • Re: computational model of transactions
    ... especially not this kind of example, since I've been a bank programmer ... operation that has the same result, associativity is also irrelevant. ... Otherwise it would mean a transaction is allowed to see uncommitted ... it necessary to serialize, since the update modifies the value that is current at the time that the update commences, not at the time that the transaction commences. ...
    (comp.databases.theory)
  • Re: serializable isolation level behavior question
    ... Again, truncate is not a query, it is not even a dml. ... The OP transaction performed casher DML statements. ...
    (comp.databases.oracle.server)