Обсуждение: AW: AW: BLERe: AW: AW: relation ### modified while in u se

Поиск
Список
Период
Сортировка

AW: AW: BLERe: AW: AW: relation ### modified while in u se

От
Zeugswetter Andreas SB
Дата:
> > > > > 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.
> >
> > E.g. a table is accessed multiple times to select different data
> > in an inner application loop. No need for serializable here.
> >
> 
> And seems no need to execute in one tx.

Yes there is, if you need to do dml based on the results of the inner loop
select statement.

> Hmm,we seems to be able to call a cleanup procedure
> internally which is equivalent to 'commit' after each
> consecutive read-only statement.  Is it a problem ?

Which would, in the locking sense be the same thing as 
releasing the shared lock after each read only statement.

It would only be done if the current tx did not modify any 
data yet. This is imho an awkward praxis that we should avoid at all
costs.

I have seen Oracle apps that start out with an update to a dummy 
table, just to be sure the transaction started. This is nonsense,
that we imho don't want to copy.

Also the result would be, that the first readonly statements are allowed to 
see schema changes, but selects after the first DML would not :-(

Andreas


Re: AW: AW: BLERe: AW: AW: relation ### modified while in use

От
Hiroshi Inoue
Дата:

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.
Hiroshi Inoue