Re: computational model of transactions

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.
I understand and agree with this last point. As I mentionned this is a complex problem and a simplyistic solution just won't do it.

My guess is that concurrency and isolation is at the boundary between RM and network issues. It must respect RM requirements but at the same time, RM can not bring all answers to such problem. A model, if it is to be defined some day, should probably take into account the problem of integration between some of OSI layers (probably transport layer level) and RM preservation of integrity. I hate the word, but I would almost dare to say that concurrency is almost orthogonal to RM...

> p
Received on Tue Aug 01 2006 - 23:36:26 CEST