Re: Theoretical Basis for SELECT FOR UPDATE

Jonathan Leffler wrote:
> vc wrote:

[...]

> >>> Moreover, I bet that 'update,update;' has to use the same
> >>> mechanism behinds the scenes, namely deferrable constraints (what
> >>> else?), in order to be possible.
> >>
> >>No; the sequence is defined as 'do all the operations; check all the
> >>constraints'.
> >
> > Are you saying that update,update; is treated as a single atomic
> > operation in which case the constraints needn't be deferrable,
>
> Yes. The 'comma' separating the 'statements' means there are actually
> two separate sub-statements (either of which could be treated as a
> standalone statement) that are tied together to form a single statement.
>
> > or you mean something completely different? If you mean the former,
> > how do you imagine such concatenated update might be implemented
> > without dramatic negative impact on concurrency and therefore on
> > performance?
>
> The implementation is substantially the same as the implementation of a
> single update - make changes then validate those changes. The two
> statements are prepared as a single unit, so the optimizer can combine
> the operations completely.
>
> >>>All in all, the comma separated statements do not appear to bring much
> >>>new to the table in comparison to the commit-delimited old style
> >>>transactions except for perhaps more concise notation.
> >>
> >>They leave you with the option of having complex constraints that are
> >>not violated at any point. The alternative leaves you with a complex
> >>constraint that is violated at the intermediate point.
> >
> >
> > Please explain how the complex constraint is not violated at any point
> > in a multistatement comma separated expression.
>
> The system ensures that while the single statement is running, no-one
> else gets to see the modified rows[...]

I doubt that it's a very useful technique. Essentially, with this approach, you make even read access to the union of all the rows referenced in the compound statement sequential. It's much worse than what the old transaction has already to offer.

• unless they're running at a dirty
  > read isolation in which case the inaccuracies are (by definition of
  > dirty read) immaterial.
  

It's a separate subject, but who in his sane mind would want to use dirty reads that by definition produce garbage?

>
>
> --
> Jonathan Leffler #include <disclaimer.h>
> Email: jleffler_at_earthlink.net, jleffler_at_us.ibm.com
> Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/
Received on Wed Oct 05 2005 - 15:18:37 CEST