Re: Version 6 locking with INSERT stmnts

In article <1993Jul2.163348.99472_at_embl-heidelberg.de> hazledine_at_embl-heidelberg.de writes:

>Page 12-25 of the Version 6.0 DBA Guide states that:
>
>"If ROW_LOCKING is set to ALWAYS (the default value for ORACLE with the
>transaction processing option) and you change data in a table (via INSERT,
>UPDATE, or DELETE), then other users can update other rows in the same table
>while your transaction is active".
>
>On our system (Version 6.0.36.7 with TPO running under VMS) this does not apply
>to INSERT statements when the table concerned has at least one unique index.
> In
>this case the first user to INSERT obtains an exclusive lock and other users
> who
>try to INSERT have to wait. Since we have several applications performing
>INSERTs and we have unique indexes on all primary keys, we see no improvement
>over Version 5 so far as lock contention is concerned. Sigh.
>
>Can anyone confirm that this is indeed the case, or are we missing something?

I believe this is one of those sad facts of life (it happens in other databases as well) and would require predicate locking to get around. It's all to do with B-trieve implementation (of course) so it doesn't happend with unindexed tables.

I was brought up to do commits as soon as possible after Inserts/Updates etc and certainly never allowing user interaction in between. I wince (a little) at applications which allow SQL rollback.

-- 
Chris Jack