Re: computational model of transactions
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Fri, 04 Aug 2006 15:07:16 GMT
Message-ID: <EoJAg.34255$pu3.448878_at_ursa-nb00s0.nbnet.nb.ca>
>>"Erwin" <e.smout_at_myonline.be> wrote in message
>>
>>>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.
Date: Fri, 04 Aug 2006 15:07:16 GMT
Message-ID: <EoJAg.34255$pu3.448878_at_ursa-nb00s0.nbnet.nb.ca>
Marshall wrote:
> Brian Selzer wrote: >
>>"Erwin" <e.smout_at_myonline.be> wrote in message
>>
>>>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.
> > This assumes the existence of an atomic addition operator; > no such operator exists as far as I know. It is always > read-add-write.
Whether it is atomic depends on the hardware architecture just as it does for test-and-set.
Given that read and write occur at separate
> times, a race condition exists. *Something* has to be done > about the race condition, whatever the logical model. > > What you say above would make sense in the presence of > an atomic "+=" operator a la C's +=. But it has to be atomic.
If I recall correctly, which is highly suspect, the PDP-11 can add to a word of memory. Received on Fri Aug 04 2006 - 17:07:16 CEST