Re: dbms_lock.allocate_unique and autonomous transactions (long)

vc wrote :

> hasta_l3_at_hotmail.com wrote:
> [...]
> > More concretely, the whole list structure is being changed,
> > and the change should be atomic with regard to other
> > operations that may also change the structure. However,
> > the short transactions - which dont care about the structure -
> > should not block.
>
> So only the transactions modifying the entire list would select for
> update the list header and therefore be executed serially, the
> smaller transactions that do not care about the list structure would
> proceed in the usual way without locking the header first. What is the
> problem ?

Assume a (long) restructuring operation L modifies (a) some fields of the list header row in the master table, then (b) some fields of every list line row in the children table, including -say - row R.

Assume that a short transaction S modifies (a) some (other) fields of the list line row R.

If L is in a single long transaction, then it will block S if S happens to want to modify R after L did it. Received on Wed Nov 01 2006 - 09:32:22 CST