Re: computational model of transactions
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 02 Aug 2006 01:55:38 GMT
Message-ID: <uCTzg.32008$pu3.428175_at_ursa-nb00s0.nbnet.nb.ca>
>> paul c wrote:
>>
>>> paul c wrote:
>>>
>>>> Bob Badour wrote:
>>>> ...
>>>>
>>>>>>>> While that's sometimes necessary, the batch processes I referred
>>>>>>>> to did not all do that. They just grouped multiple logical units
>>>>>>>> of work together before issuing a commit. Serializing was
>>>>>>>> handled by the normal concurrency features and isolation level.
>>>>>>>> ...
>>>>
>>>> In that case, you are talking about serialization and not
>>>> recognizing it.
>>>>
>>>> p
>>>
>>> (To clarify, if the so-called luw's could have been run in parallel
>>> with an acceptable result, the issue of concurrency is moot.
>>
>> Indeed. In fact, it was possible to run multiple batches in parallel.
>> This makes concurrency very relevant not moot.
>>
>> I think luw is
>>
>>> synonomous with transaction in Gray's sense, even though I know some
>>> programmers think program trumps transaction. But then I think
>>> programmers are servants, not arbiters.)
>>
>>
>> A logical unit of work must be treated as atomic. Thus, if part of the
>> work is rolled back, it must all be rolled back. This is how one
>> usually identifies what must go into a single transaction.
>>
>> Combining an integral number of logical units of work into a single
>> transaction, however, does not introduce any risk of inconsistency.
>> That is, there is no theory or argument preventing one from combining
>> them. Marshall's suggestion, on the other hand, would prevent them.
Date: Wed, 02 Aug 2006 01:55:38 GMT
Message-ID: <uCTzg.32008$pu3.428175_at_ursa-nb00s0.nbnet.nb.ca>
paul c wrote:
> Bob Badour wrote: >
>> paul c wrote:
>>
>>> paul c wrote:
>>>
>>>> Bob Badour wrote:
>>>> ...
>>>>
>>>>>>>> While that's sometimes necessary, the batch processes I referred
>>>>>>>> to did not all do that. They just grouped multiple logical units
>>>>>>>> of work together before issuing a commit. Serializing was
>>>>>>>> handled by the normal concurrency features and isolation level.
>>>>>>>> ...
>>>>
>>>> In that case, you are talking about serialization and not
>>>> recognizing it.
>>>>
>>>> p
>>>
>>> (To clarify, if the so-called luw's could have been run in parallel
>>> with an acceptable result, the issue of concurrency is moot.
>>
>> Indeed. In fact, it was possible to run multiple batches in parallel.
>> This makes concurrency very relevant not moot.
>>
>> I think luw is
>>
>>> synonomous with transaction in Gray's sense, even though I know some
>>> programmers think program trumps transaction. But then I think
>>> programmers are servants, not arbiters.)
>>
>>
>> A logical unit of work must be treated as atomic. Thus, if part of the
>> work is rolled back, it must all be rolled back. This is how one
>> usually identifies what must go into a single transaction.
>>
>> Combining an integral number of logical units of work into a single
>> transaction, however, does not introduce any risk of inconsistency.
>> That is, there is no theory or argument preventing one from combining
>> them. Marshall's suggestion, on the other hand, would prevent them.
> > Yes, as I recall, Marshall talked of more than one transaction. But if > certain multiple transactions have the same result as one, there is no > issue of concurrency, IMHO.
I have no idea where you got the idea that anything I said related to multiple transactions having the same result as one. Nor can I recognize any logic that would discount the relevance of concurrency in anything you wrote. Received on Wed Aug 02 2006 - 03:55:38 CEST