At 09:36 25/10/00 +0200, Zeugswetter Andreas SB wrote:
>
>> I have not followed the entire thread, but if you are in a serializable OR
>> repeatable-read transaction,
>
>Serializable and repeatable read are the same thing, different wording.
Not last time I looked. RR ensures that rows you have s
> I have not followed the entire thread, but if you are in a serializable OR
> repeatable-read transaction,
Serializable and repeatable read are the same thing, different wording.
> I would think that read-only statements will
> need to keep some kind of lock on the rows they read (or the tabl
> > > > > Are there many applications which have many SELECT statements(without
> > > > > FOR UPDATE) in one tx ?
> > > >
> > > > Why not ?
> > > >
> > > It seems to me that multiple SELECT statements in a tx has little
> > > meaning unless the tx is executed in SERIALIZABLE isolation level.
> >
>
Zeugswetter Andreas SB wrote:
[snip]
>
> Also the result would be, that the first readonly statements are allowed to
> see schema changes, but selects after the first DML would not :-(
>
Does it mean that even read-only statements aren't allowed
to release locks after other DMLs ?
Regards.
Hi
> > Also the result would be, that the first readonly statements are allowed to
> > see schema changes, but selects after the first DML would not :-(
>
> Does it mean that even read-only statements aren't allowed
> to release locks after other DMLs ?
That is, what Tom is suggesting, but not afte