Re: computational model of transactions

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

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.

His suggestion creates a situation rather like the problems created by aliasing due to reference parameters only in reverse. Instead of an update inadvertently clobbering a variable, the proposal would refuse to clobber it. Received on Wed Aug 02 2006 - 02:48:02 CEST