Re: computational model of transactions

From: paul c <toledobythesea_at_oohay.ac>
Date: Wed, 02 Aug 2006 00:57:47 GMT
Message-ID: <fMSzg.305148$Mn5.193880@pd7tw3no>

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.

p Received on Tue Aug 01 2006 - 19:57:47 CDT