When a user attempts to update or delete rows from a table, she acquires
exclusive row level locks on the rows in question. Other queries which wish to
access these rows for update or delete must wait until the first user finishes,
unless the other users are issuing a select on the rows. In the case where the
other users issue a select (which is a read-only transaction), they see the
(not yet deleted) data for these rows which is stored in the rollback segments.
Kopeche?
>Subject: Automatic Locking
>From: Bernadette Pinto <b.pinto_at_zetnet.co.uk>
>Date: 8/26/98 1:05 PM EST
>Message-id: <1998082619055476740_at_zetnet.co.uk>
>
>I need help on this urgently. Please respond!!
>
>My problem is this:
>
>Can someone explain (in beginner - speak) how automatic locking is
>handled in a multi - user environment? I am particularly curious
>about two users who are performing DML upon the same table but not
>committing their actions. What will happen when one commits before
>the other? What will happen to the row / columns which have been
>deleted when the other user attempts to update them?
>Are the table.rows flagged as deleted and thusly locked to the other
>user? Or, if the updating user manages to update first are these rows
>flagged as updated and thusly inaccessible?
>How does it work? I really appreciate any answer.
>
>Thanks
>
>B. Pinto
>
>
Received on Wed Aug 26 1998 - 22:21:10 CDT
