Re: computational model of transactions
From: Brian Selzer <brian_at_selzer-software.com>
Date: Sat, 05 Aug 2006 03:13:56 GMT
Message-ID: <U1UAg.1200$1f6.933_at_newssvr27.news.prodigy.net>
>> "Brian Selzer" <brian_at_selzer-software.com> wrote in message
>> news:voHAg.4447$uo6.79_at_newssvr13.news.prodigy.com...
>>
>>>"Erwin" <e.smout_at_myonline.be> wrote in message
>>>news:1154689817.830401.130180_at_75g2000cwc.googlegroups.com...
>>>
>>>>>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.
>> 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.
>>
>>
Received on Sat Aug 05 2006 - 05:13:56 CEST
Date: Sat, 05 Aug 2006 03:13:56 GMT
Message-ID: <U1UAg.1200$1f6.933_at_newssvr27.news.prodigy.net>
"J M Davitt" <jdavitt_at_aeneas.net> wrote in message news:QVSAg.63281$Eh1.62802_at_tornado.ohiordc.rr.com...
> Brian Selzer wrote:
>> "Brian Selzer" <brian_at_selzer-software.com> wrote in message
>> news:voHAg.4447$uo6.79_at_newssvr13.news.prodigy.com...
>>
>>>"Erwin" <e.smout_at_myonline.be> wrote in message
>>>news:1154689817.830401.130180_at_75g2000cwc.googlegroups.com...
>>>
>>>>>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.
> > Are we to understand that "it's possible to have several other > intervening transactions commit between the time that the > transaction starts and the time that the update starts" means > that you believe that at "the time the update starts" the value > of whatever attribute is being changed isn't the same as it was > when the transaction started? >
Yes. The nature of the update makes this possible. An update that simply decreases inventory by 5 need not know the state of the inventory at the time that the transaction started. If you issue,
UPDATE Inventory
SET ON_HAND = ON_HAND - 5
WHERE PartNo = '1322314'
AND Warehouse = 'Cleveland'
AND Bin = 'F2A31S3B6'
then it doesn't matter what the value was at the start of the transaction, since the current value is read out during the update; whereas, if you issue:
UPDATE Inventory
SET ON_HAND = 25
WHERE PartNo = '1322314'
AND Warehouse = 'Cleveland'
AND Bin = 'F2A31S3B6'
then it does matter because the value, 25, represents 5 less then the value that existed at the start of the transaction. Also in this case intervening transactions cannot have occurred, otherwise the values set by the intervening transactions will be overwritten. Hence with replacement, the row to be updated must be reserved for exclusive use (at least for writing) throughout the transaction.
> (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.
>>
>>
Received on Sat Aug 05 2006 - 05:13:56 CEST