Re: Theoretical Basis for SELECT FOR UPDATE

Tony Andrews 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.

Yes, that's possible at the expense of forcing all the potentially concurrent transactions modifying a common set of rows execute serially. The price of doing so is rather high.

>
> > >I imagine DB2 et al already have something like that?
> >
> > It does not.
>
> Really? How do they performs sorts then?

They sort in the temporary tablespace, but how does having temp t.s. help us with having access to the last committed row values ? If you meant the locking approach you should have said so since that's what defines how exactly we can save row values, the place where we can store them is of secondary importance.

>(I realise you mean, "does
> not have multi-versioning", but that was NOT what I suggested they had,
> was it?

I do not know what you'd suggested by saying "DB2 et al already have something like that". I decided, incorrectly, that "something like that" meant some form of multiversioning.

>
> Anyway, this is all rather moot because the TTM's model for multiple
> assignment is not intended to be implemented in DB2 or any other SQL
> DBMS...
Well, it's surely intended to be implemented somehow is not it, so we can at least speculate on how it might be implemented. Received on Thu Oct 06 2005 - 14:29:32 CEST