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.
When you start the second session the first session has an exclusive lock on table d because of your uncommitted insert. Hence when it comes to foreign key checking, and as you didn't define an index on your foreign key column, your second session will too try to obtain a table level exclusive lock on your table d. Evidently, it won't get that, 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.
You need to create an index on your foreing key column and/or issue appriopate update commands
(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 - 08:19:15 CST