Re: Bad theory

"Alexander Chupin" <chupin_at_hotmail.ru> wrote in message news:98l7nv$3td$1_at_soap.pipex.net...
> Unfortunately,
>
> I almost believe that this is very depth bug.
> especially I was surprised that this bug can be
> reproduced at different versions and different
> platforms. I'm going to check this effect for Oracle 7
> version.
>
> Thank you for your attention.
>
> "Frank" <franjoe_at_frisurf.no> wrote in message
> news:nHar6.4109$tR1.45439_at_news1.oke.nextra.no...
> > Hi!
> >
> > Sorry! - bad suggestion :-|
> >
> > Frank
> >
> >
>
>
Some people just shout 'bug' too often.
[Quoted] When you start the second session the first session has an exclusive lock on [Quoted] table d because of your uncommitted insert. [Quoted] Hence when it comes to foreign key checking, and as you didn't define an [Quoted] index on your foreign key column, your second session will too try to obtain [Quoted] a table level exclusive lock on your table d. Evidently, it won't get that, [Quoted] and it will wait forever, as this is not a deadlock.

Hence, this is *NOT* a bug, and without any doubt this will be the reply of OTS when you are going to submit a TAR.
[Quoted] You need to create an index on your foreing key column and/or issue appriopate update commands
[Quoted] (as you probably are not aware, an update without select for update or without a previous lock table in row share mode also results in a table level exclusive lock)

Regards,

Sybrand Bakker, Oracle DBA Received on Tue Mar 13 2001 - 15:19:15 CET