Assume that one user is updating a row in a table through an application.
Now if another user is tries to update that same row(at the same time) he should not be able to update the row. I am planning to throw a message to the second user saying "This row is being updated by some other user".
Now the first user should lock the row before updating.
So please let me how to lock that particular row.
Please go through the details below. I think it will be helpful to u
> IN (Intent None) Table spaces, tables The lock
> owner can read any data in
> the table, including uncommitted data, but cannot
> update any of it. No row
> locks are acquired by the lock owner. Other
> concurrent applications can read
> or update the table.
> IS (Intent Share) Table spaces, tables The lock
> owner can read data in the
> locked table, but not update this data. When an
> application holds the IS
> table lock, the application acquires an S or NS lock
> on each row read. In
> either case, other applications can read or update
> the table.
> NS (Next Key Share) Rows The lock owner and all
> concurrent applications
> can read, but not update, the locked row. This lock
> is acquired on rows of a
> table, instead of an S lock, where the isolation
> level is either RS or CS on
> data that is read.
> S (Share) Rows, tables The lock owner and all
> concurrent applications can
> read, but not update, the locked data. Individual
> rows of a table can be S
> locked. If a table is S locked, no row locks are
> IX (Intent Exclusive) Table spaces, tables The
> lock owner and concurrent
> applications can read and update data in the table.
> When the lock owner
> reads data, an S, NS, X, or U lock is acquired on
> each row read. An X lock
> is also acquired on each row that the lock owner
> updates. Other concurrent
> applications can both read and update the table.
> SIX (Share with Intent Exclusive) Tables The lock
> owner can read and
> update data in the table. The lock owner acquires X
> locks on the rows it
> updates, but acquires no locks on rows that it
> reads. Other concurrent
> applications can read the table.
> U (Update) Rows, tables The lock owner can update
> data in the locked row
> or table. The lock owner acquires X locks on the
> rows before it updates the
> rows. Other units of work can read the data in the
> locked row or table; but
> cannot attempt to update it.
> NX (Next Key Exclusive) Rows The lock owner can
> read but not update the
> locked row. This mode is similar to an X lock except
> that it is compatible
> with the NS lock.
> NW (Next Key Weak Exclusive) Rows This lock is
> acquired on the next row
> when a row is inserted into the index of a
> non-catalog table. The lock owner
> can read but not update the locked row. This mode is
> similar to X and NX
> locks except that it is compatible with the W and NS
> X (Exclusive) Rows, tables The lock owner can both
> read and update data in
> the locked row or table. Tables can be Exclusive
> locked, meaning that no row
> locks are acquired on rows in those tables. Only
> uncommitted read
> applications can access the locked table.
> W (Weak Exclusive) Rows This lock is acquired on
> the row when a row is
> inserted into a non-catalog table. The lock owner
> can change the locked row.
> This lock is similar to an X lock except that it is
> compatible with the NW
> lock. Only uncommitted read applications can access
> the locked row.
> Z (Superxclusive) Table spaces, tables This lock
> is acquired on a table in
> certain conditions, such as when the table is
> altered or dropped, an index
> on the table is created or dropped, or a table is
> reorganized. No other
> concurrent application can read or update the table.