Re: computational model of transactions

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 01 Aug 2006 23:03:46 GMT
Message-ID: <m5Rzg.31902$pu3.425943@ursa-nb00s0.nbnet.nb.ca>

paul c wrote:

> Bob Badour wrote:
> 

>> paul c wrote:
>>
>>> Bob Badour wrote:
>>>
>>>> paul c wrote:
>>>> ...
>>>> What if one combines multiple logical units of work into a single
>>>> transaction? I have seen this done for performance in batch
>>>> processes to faciliate effective physical buffering etc. With
>>>> Marshall's proposal, this would not be possble.
>>>
>>>
>>> So have I, and the batch process was usually serialized in one way or
>>> another, either by suspending certain other transactions or even by
>>> kicking all users off the system.
>>
>>
>> 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.
>>
>> Thus, the batch might issue 10 commits for 1000 logical units of work
>> by only committing after every 100th one. For larger logical units of
>> work, the batch might issue 100 commits by committing after every 10th
>> one.
>>
>> There is a performance tradeoff between how much of the log is used
>> for uncommitted transactions vs. how efficiently the batch uses the
>> network resources. Plus, one has to consider that a rollback will
>> revert multiple logical units of work.

> 
> Like give all 100,000 employees a 10% raise.  Still, that kind of commit 
> is not what I call a logical commit, suggesting that a commit doesn't 
> mark a luw boundary.  I've heard it called an 'intermediate', aka 
> physical, commit.

There is nothing intermediate about it. I think you are talking about splitting logical unit of work into multiple units of work, which is something entirely different. Your comment suggests to me you have worked with Oracle and it's, ahem, wasteful and unforgiving use of rollback segments.

Instead of committing after every transaction the batches committed after every n transactions. Now, I realize that makes them all part of the same transaction in terms of begin transaction/commit transaction, but in terms of serializability, this introduces no risk.

The batches were more along the lines of: I have a file from a different source that describes all the changes to the employment records of all the employees for the last period, and now I have to apply those changes to my database. An individual logical unit of work might update two or three tables, and the update would have to be atomic. Instead of committing after each logical unit of work, the batch program would process a bunch of them before issuing a commit. Received on Tue Aug 01 2006 - 18:03:46 CDT