You might get a table lock when scanning the whole table (as a select
without a predicate will do). However, this query would not succeed
even if row locking was used, since the scan would be blocked by the
lock on (c,d).
Except when using 'read uncommitted' isolation level, a query will be
blocked when it encounters a row with uncommitted changes.
--
Øystein
>>>>> "MS" == Mehran Sowdaey <[EMAIL PROTECTED]> writes:
MS> The actual default behavior that we see is table level locking when
MS> autocommit is turned off not row level locking. Simple test:
MS> Before lock:
MS> Session 1, and Session 2 can see this row:
ij> select * from mscolor;
MS> COL1 |COL2
MS> ---------------------
MS> a |b
MS> 1 rows selected
ij>
MS> After lock:
MS> Session 1:
ij> autocommit off;
ij> insert into mscolor values ('c', 'd');
MS> 1 row inserted/updated/deleted
ij>
MS> Session 2:
ij> select * from mscolor;
MS> COL1 |COL2
MS> ---------------------
MS> ERROR 40XL1: A lock could not be obtained within the time requested
ij>
MS> Session 2 can not see anything until session 1 commits or rolls back.
