Discussion :

[schnourf]

Plutot que de faire un petit discours, je commence par le script

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
drop table t;
creat table t ( id number primary key, y number,z number ); 
ALTER TABLE t ADD ( CONSTRAINT FK1 
FOREIGN KEY (z) REFERENCES t (id)); 
insert into t values ( 1, 1 ,null); 
insert into t values ( 2, 2 ,null); 
commit;

PS: j'ai eu quelques difficultés à poster ce post, en effet lorsque j'ecrivais "CREATE TABLE" mon post ne voulais pas se laisser creer, d'ou la petite faute de frappe au dessus.

Ensuite faire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select null from t where id = 1 for update nowait;

Puis ouvrir une nouvelle session et faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
select null from t where id = 2 for update nowait;
 
declare 
r t%rowtype; 
begin 
select * into r from t where id = 1; 
update t set row = R where id = 1; 
end;

Vous remarquerez que dans ce cas la session 2 bloque la session 1 comme si la session 2 avais fait un select for update sur l'Id 1

Si on désactive la Foreign Key tout se passe bien .

J'estime que c'est un bug d'oracle. Qu'en pensez-vous ?
SI je me souviens bien de mes premiers tests, si on liste toutes les colonnes pour l'update tout se passe bien. Maintenant lorsqu'on a des talbes avec plus de 150 colonnes, il est très confortable de pouvoir utiliser la Syntaxe Row = ...

Est-ce que d'autres ont rencontré le même probleme ? Comment l'avez vous résolu ?

D'avancee merci de votre aide

[schnourf]

Bon, apparement personne ne connaît la reponse.

Mais j'ai quand même une bonne nouvelle, mon collegue, après de longue recherches, a decouvert qu'il fallait créer un index sur la foreign key et alors cela fonctionne.