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 Tue Aug 01 2006 - 20:55:38 CDT
