Re: Theoretical Basis for SELECT FOR UPDATE

"Tony Andrews" <andrewst_at_onetel.com> wrote
> vc wrote:
> > Tony Andrews wrote:
> > > More or less maybe, but you DON'T need the full works of
> > > multi-versioning just to store data temporarily; you just need a TEMP
> > > data area or enough memory.
> >
> > A simplistic "save just before" clearly is not enough, in the first
> > place because during the time taken to read and store the 'before'
> > value, the value may get too old due to the fact that another
> > concurrent transaction may have just produced a newer version. A
> > solution is to make the transaction that creates a new row version
> > responsible for maintaining the version store.
>
> A simplistic "lock rows" and "save just before" then.

Just as an aside, Oracle Rdb (formerly DEC Rdb) maintains "snapshot data" by putting the burden on the updating transaction. The burden is rather light in the case of inserts and deletes, but it's kind of heavy in the case of updates.
The burden can be eliminated by shutting snapshot transactions off.

The concurrency problem that VC suggested above isn't a new problem if the updater does the save before. It's the same concurrency problem that must be dealt with in order to make concurrent updates to the same row serializable. If the concurrency manager managers concurrent updaters correctly, it will also manage snapshotters correctly.

Multiple updaters could result in multiple snapshots of the same row. Received on Thu Oct 06 2005 - 16:01:57 CEST