----------- the Oracle ------------------
the Oracle's row lock for update
Key words: oracle of row locks for update
syntax SELECT ... FOR UPDATE statement is as follows:
SELECT ... FOR UPDATE [OF column_list] [the n-WAIT | NOWAIT] [SKIP LOCKED];
where:
OF clause is used to specify the column being updated, That particular column on the row lock.
WAIT clause specifies wait for another user to release the lock of seconds, to prevent an indefinite wait.
Advantage "Use FOR UPDATE WAIT" clause as follows:
1 prevent wait indefinitely locked row;
2 allows the application of more control wait time locks.
3 very useful for interactive applications, because users can not wait for these uncertain
4 If you use a skip locked, the lock can cross the line, does not report triggered by the wait n 'resource busy' exception reporting
Example. 1:
Create Table T (A VARCHAR2 (20 is), B VARCHAR2 (20 is));
INSERT INTO T values ( '. 1', '. 1');
INSERT INTO T values ( '2', '2');
INSERT INTO values T ( '. 3', '. 3');
INSERT INTO T values ( '. 4', '. 4');
now perform the following operations:
open two windows sql plsql develope in
run 1 sql window
select * from t where a = '1' for update;
run 2 sql1 window
1. select * from t where a = '1'; this is no problem, because the row-level locks do not affect pure select statements
run SQL2
2 . select * from t where a = '1' for update; sql then this one, when executed, always in a wait state, unless the window 1 sql committed or rolled back.
How can sql2 not wait or wait for a specified time? We run SQL3
3. the SELECT * t from the WHERE A = '1' for Update nowait; when you execute this sql, directly reported to the busy resource exception.
If the execution select * from t where a = ' 1' for update wait 6; then after waiting for 6 seconds, the resource busy message exception.
If we execute sql4
4. select * from t where a = '1' for update nowait skip Locked; the execution sql, i.e. without waiting, busy resources nor reported anomaly.
Now we look at the implementation follows what will happen?
Performed in the window. 1:
SELECT * WHERE rownum from T <= Skip Locked nowait. 3;
execution window 2:
SELECT * WHERE rownum from T <= Skip Locked nowait. 6;
SELECT Thus it will for Update, insert, update , delete the default operation plus row-level locking, the principle and operation of the select for update is no different.
select for update of, when the clause is implicated of a plurality of tables, has a large effect, without the use of a specified list of locked, all associated tables are locked rows, if in need of specified modified column, only the lines associated with these columns in the table will be locked.
Examples 2
Elect from t * Update will wait for after the row lock is released, return query results.
select * from t for update nowait does not wait for the line to release the lock, the lock prompts conflict, does not return results
select * from t for update wait 5 wait five seconds, if the trip has not yet released the lock, the lock prompts conflict, does not return a result
select * from t for update skip locked query return query results, but ignores the record row lock
——————————— MySQL —————————————————–
Problems MySQL select * for update lock table
Page level: Engine BDB.
Table-level: engine MyISAM, understood to lock the entire table, you can simultaneously read and write not
row-level: engine INNODB, a separate line record locking
table-level, direct lock the entire table, you lock in period, not the other process table for writing. If you are a write lock, then other processes are not allowed to read
row-level ,, only specified record lock, so that other processes can still operate on other records in the same table.
Page-level, table-level locking is fast, but more conflict, less row-level conflict, but slower. So take a page-level compromise, once locked a group of adjacent records.
MySQL 5.1 support for MyISAM and MEMORY tables for table-level locking for BDB tables page-level locking, InnoDB tables on row level locking.
To WRITE, MySQL uses table locking method works as follows:
if there is no lock on the table, put it above a write lock.
Otherwise, the lock request on the write lock queue.
The principle READ, MySQL uses locking method is as follows:
If you do not write lock, put a read lock placed on it on a table
Otherwise, the lock request on the read lock queue.
InnoDB uses row locks, BDB uses page locks. For both storage engines, deadlocks are likely to exist. This is because, during processing the SQL statement, InnoDB row lock automatically and BDB obtain page locks, rather than get in the transaction starts.
MySQL select * for the problem update lock table
because the InnoDB default is Row-Level Lock, so only "clear" in the specified primary key, MySQL will perform Row lock (lock only data cases to be selected), or else MySQL will perform Table Lock (to lock the entire information form).
For example:
Suppose there are two forms products, there are two fields id with name, id is the primary key.
Example 1: (explicitly specify the primary key, and the pen has this information, Row Lock)
the SELECT * the FROM the WHERE ID = Products '. 3' the FOR the UPDATE;
the SELECT * the FROM the WHERE ID = Products '. 3' = 1 and the FOR type the UPDATE;
Example 2: (primary key explicitly specified, if the information requested does not exist pen, no Lock)
the SELECT * the FROM Products the WHERE ID = '-. 1' the FOR the UPDATE;
例2: (无主键，table lock)
SELECT * FROM products WHERE name=’Mouse’ FOR UPDATE;
Example 3: (primary key is not clear, Table Lock)
the SELECT * the WHERE the FROM Products ID <> '3' the FOR the UPDATE;
例4: (主键不明确，table lock)
SELECT * FROM products WHERE id LIKE ‘3’ FOR UPDATE;
Note 1: FOR UPDATE only applies to InnoDB, and must take effect on the trading block (BEGIN / COMMIT) in.
Note 2: To test the lock status, you can use the MySQL Command Mode, open two windows to do the test.
In MySql 5.0 test is indeed the case
in addition: MyAsim supports only table-level locking, InnerDB supports row-level locking
is added (row-level locking / table-level lock) lock data can not be re-locked by other transactions not be modified by other transactions (modify, delete)
is a table-level lock time, regardless of whether or not to record the query will lock the table
About Oracle in the supplement for update:
Divided into two categories: scope clause lock and locking behavior clause
Lock range clause:
In the select ... for update after the clause may be used to select specific data of the table for locking the select operation. By default, the lock is not used in the select clause indicates that of all the data in the table
Locking behavior clause:
When we carry out the operation for update, select the ordinary there is a big difference. Generally select is not necessary to consider whether the data is locked up to read the previous version of the multi-version read consistency properties. After adding for update, Oracle requires to start a new transaction, try to lock the data. If the current has been locked, the default behavior is to block waiting for the inevitable. Use role nowait clause is to avoid waits, discovery request when the resource is locked when the lock is not released directly return an error.
In daily life, we use for update is quite common, especially in such as pl / sql developer manually modify the data. At this time, just find it convenient, while the true meaning for update lack of understanding.
For update statement is a special case of the manual lock to improve the level and scope of Oracle. Oracle's locking mechanism is the various types of database lock mechanism in relatively good. Therefore, Oracle does not need to consider the general user and application control and direct lift lock. Even think of such a deadlock scenario appears lock-related issues, mostly related to manual lifting lock. Therefore, Oracle is not recommended for update as a daily use development. Moreover, in the normal development and operation and maintenance, but forgot to use for update submitted, it will cause a lot of table lock failure.
So, when you need to use for update? That is, those who need the business level data exclusivity, consider using for update. When on the scene, such as booking tickets, stamps displayed on the screen, while the real carried out the ticket, the need to redefine what this data has not been modified by other clients. Therefore, in this confirmation process can be used for update. This program is a unified solution to the problem, we need to be prepared early.