Re: computational model of transactions

"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message news:6DSzg.31969$pu3.427010_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.
>

Here's an argument: let's say that you combine 10 logical units of work into a single transaction, and one fails, requiring a rollback. Well, now 9 units of work that would have committed didn't. While it may not introduce risk of inconsistency within the database, if the kludge you're using to combine luw's doesn't have robust recovery code built in, you run the risk of losing information.

> 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 - 22:38:00 CEST