Re: serializable isolation level behavior question

Laurenz Albe <invite_at_spam.to.invalid> wrote:
> Bob Jones <email_at_me.not> wrote:
> >> Session 2 (isolation level serializable)
> >>
> >> Set transaction isolation level serializable
> >>
> >> Select * from dd; (2 rows returned at this point)
> >>
> >> Now truncate the table from session1:
> >> Truncate table dd; (issue implicit commit)
> >>
> >> Now again run the following select from session 2:
> >>
> >> Select * from dd; (This should still shows 2 rows as
> >> read data from rollback segments since in serializable mode, it need
> >> to show the pre-image before the truncate but it is showing 0 rows)
> >>
> >> Is this expected behavior that in second session it returns 0 rows and
> >> not 2 rows?
> >
> > Yes, truncate does not generate any undo. In this case, you should use
> > delete instead.
>
> True, that explains why anybody who knows Oracle could expect this
> behaviour.
>
> But that is not standard compliant, is it?

Does the standard specify whether the *DDL* of other connections are allowed to silently breach the serializability of an unrelated transaction?

Anyway, there are more serious ways in which Oracle's transaction isolation level serializable are not truly serializable.

Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service                        $9.95/Month 30GB