Re: computational model of transactions
From: paul c <toledobythesea_at_oohay.ac>
Date: Tue, 01 Aug 2006 20:29:04 GMT
Message-ID: <kQOzg.303577$Mn5.275235_at_pd7tw3no>
>
> 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.
Date: Tue, 01 Aug 2006 20:29:04 GMT
Message-ID: <kQOzg.303577$Mn5.275235_at_pd7tw3no>
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.
p Received on Tue Aug 01 2006 - 22:29:04 CEST