Test case: unusual locking problem or expected behaviour?

Question

I have tried the following test case on both 9.0.1 and 10.2.0. The problem I am seeing here is that a table receives an exclusive lock that doesn't get trapped by a FOR UPDATE NOWAIT condition.
Test case setup
create table x (
f1 number not null,
f2 varchar2(100) );
create table y (
f1 number not null,
f2 number not null,
f3 number,
f4 varchar2(100) );
alter table x add constraint pk_x
primary key (f1);
alter table y add constraint pk_y
primary key (f1);
/*** This is a self-referential integrity check ****/
alter table y add constraint fk_y
foreign key (f3)
references y ( f1 );
create or replace trigger trig_y
before insert on y
for each row
begin
update x
set f2 = 'trig test ' || to_char(sysdate,'ddmmyyyy hhmiss')
where f1 = :new.f2;
end;
insert into x values (1,'test 1');
insert into x values (2,'test 2');
insert into x values (3,'test 3');
insert into y values (2,2,2,'y test 2');
insert into y values (3,3,3,'y test 3');
commit;
Test case actions
This requires 3 independent sessions to be started.
* SESSION 1 *
select * from x
where f1 = 1
for update nowait;
* SESSION 2 *
insert into y values (1,1,1,'test');
-- This session waits because of the trigger that is attempting to update the
-- same row that is locked in session 1.
* SESSION 3 *
select *
from y
where f1 = 2
for update of f1 nowait;
-- The row lock succeeds.
-- Now update the primary key column in Y.
update y
set f1 = 2
where f1 = 2;
-- This update statement waits because of a lock. Why is this as the row
-- has been successfully locked by the FOR UPDATE?
-- Remove the foreign key constraint from table Y and try again. This time
-- the update will not wait but will complete successfully.
Is this expected behaviour, or a bug in self-referential integrity checks, or in
all foreign keys? The reason this came about in our application is because FORMS attempts to update every column on a block regardless of whether all values in the block have changed. This includes the primary key columns.
We have worked around this issue for now by setting the 'update changed columns only' property on blocks in the forms.

Answer 1

No. All you are doing there is stating your intention of later updating the selected locked rows.
You may not even update any rows, if the program logic decides that way. Your actual update is the only case where the validation of foreign key will be applied. It cannot be done at the time of doing FOR UPDATE select, since the database does not know what new value is going to be when you do update so it is not possible to check.
Also, note that yoru statement did NOT fail. It was just rying to validate your foreign key, and in that process wants to make sure no one else makes the changes. The statement was waiting for resource to be free, it DID NOT FAIL (no error was raised).