Re: dbms_lock.allocate_unique and autonomous transactions (long)

>
> I am led, by what you've written, to question whether you understand
> basic Oracle architecture and concepts. I still don't quite see this
> as being anything more than overcomplicating something unnecessarily.
>
> Oracle is not SQL Server. Why is it that any locking is required?

I never used SQL Server, Daniel.

To recap the context :

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

Right now, that problem is solved by breaking the long operation in many small transactions.

I'm just enumerating ways to replace the burst of thousands of transactions by a single long one, if profiling shows it to be necessary. Received on Sat Nov 04 2006 - 13:34:26 CST