Re: Strange thing
From: John Hurley <johnthehurley_at_gmail.com>
Date: Tue, 12 Jun 2012 11:50:50 -0700 (PDT)
Message-ID: <42fd5b41-00aa-47ff-b37d-76887beac186_at_i19g2000yqn.googlegroups.com>
Mladen:
# if you update the parent table or delete from it, the child table
will
# still be locked, but just for the duration of the UPDATE or DELETE.
The
# lock is released after the statement is processed—not when you
commit.
# This is better than in 1993, but the lock still exists.
#
Date: Tue, 12 Jun 2012 11:50:50 -0700 (PDT)
Message-ID: <42fd5b41-00aa-47ff-b37d-76887beac186_at_i19g2000yqn.googlegroups.com>
Mladen:
#
# if you update the parent table or delete from it, the child table
will
# still be locked, but just for the duration of the UPDATE or DELETE.
The
# lock is released after the statement is processed—not when you
commit.
# This is better than in 1993, but the lock still exists.
#
Well Tom is the best source of what he was trying to convey.
Sounds like a description that with new coding by oracle their code needs to only check ( and protect against relevant changes ) the child table(s) long enough to find out if the update/delete of the parent can succeed. If it can then proceed and keep locks on parent resources being impacted but release locks on potential child resources sooner ( sooner than the old code ).
If a child row is then being attempted to being inserted by some different transaction that references a parent row that is being removed/changed by your transaction of course the lock on your parent resource keeps that in limbo. Received on Tue Jun 12 2012 - 13:50:50 CDT