Re: Theoretical Basis for SELECT FOR UPDATE
Date: 6 Oct 2005 07:13:03 -0700
Message-ID: <1128607983.157669.305400_at_g14g2000cwa.googlegroups.com>
Tony Andrews wrote:
> vc wrote:
> > 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 never said it wasn't. I merely said it was possible. Mind you, I
> have a feeling that serialisation would be required even with MV
Not with MV, no. With MV, you can get a previous version from the list of committed versions without any row/table locking, "for free" as it were, -- that's how Oracle, for example, works.
> SELECT FOR UPDATE to get the "before" data to be used in the statement.
> We can't have data on which the statement relies changing under its
> feet, can we?
Yes, you can, from the version storage. The last committed version
can be gotten either implicitely during the compound statement
execution, or explicitely by saying "select * from t1 as of some time
in the past".
>
> > 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.
>
> You don't always read carefully, do you? ;) I said: "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. I imagine DB2 et al already have something like that?"
>
> It seems clear to me that by "that" I meant "a TEMP data area or enough
> memory".
Sorry, my fault entirely.
>
> > > 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.
>
> Sure, speculate away. DB2 can introduce multi-versioning to do it, or
> it can do it by alternative means but possibly less efficiently.
Right. MS Sql Server that used to be a purely locking db does implement multiversioning in version 2005 (or rather will when it's released).
Regards. Received on Thu Oct 06 2005 - 16:13:03 CEST