Which statements are true regarding the FOR UPDATE clause in a SELECT statement? (Choose
all that apply.)
A.
It locks only the columns specified in the SELECT list.
B.
It locks the rows that satisfy the condition in the SELECT statement.
C.
It can be used only in SELECT statements that are based on a single table.
D.
It can be used in SELECT statements that are based on a single or multiple tables.
E.
After it is enforced by a SELECT statement, no other query can access the same rows until a
COMMIT or
ROLLBACK is issued.
Explanation:
FOR UPDATE Clause in a SELECT Statement
Locks the rows in the EMPLOYEES table where job_id is SA_REP.
Lock is released only when you issue a ROLLBACK or a COMMIT.
If the SELECT statement attempts to lock a row that is locked by another user, the database waits
until the row is available, and then returns the results of the SELECT statement.
FOR UPDATE Clause in a SELECT Statement
When you issue a SELECT statement against the database to query some records, no locks are
placed on the selected rows. In general, this is required because the number of records locked at
any given time is (by default) kept to the absolute minimum: only those records that have been
changed but not yet committed are locked. Even then, others will be able to read those records as
they appeared before the change (the before image of the data). There are times, however,
when you may want to lock a set of records even before you change them in your program.
Oracle offers the FOR UPDATE clause of the SELECT statement to perform this locking. When
you issue a SELECT…FOR UPDATE statement, the relational database management system
(RDBMS) automatically obtains exclusive row-level locks on all the rows identified by the SELECT
statement, thereby holding the records for your changes only. No one else will be able to change
any of these records until you perform a ROLLBACK or a COMMIT.
You can append the optional keyword NOWAIT to the FOR UPDATE clause to tell the Oracle
server not to wait if the table has been locked by another user. In this case, control will be returned
immediately to your program or to your SQL Developer environment so that you can perform other
work, or simply wait for a period of time before trying again. Without the NOWAIT clause, your
process will block until the table is available, when the locks are released by the other user
through the issue of a COMMIT or a ROLLBACK command.
then why last option is not correct??
You can query locked rows, you can not change them.
taking into account what “Gabriel K” mentioned above,
I think that E (assuming it not correct) could be a little less ambiguous, for example…
After it is enforced by a SELECT statement, no other “session” can “update/delete” the same rows until a COMMIT or ROLLBACK is issued.
… however other subsequent DMLs in the same transaction as the SELECT … FOR UPDATE … can update these rows.