NoLocks // 1.9.8b10 adoption of record locks. Feedback

[erne]

On Domenica, lug 6, 2003, at 21:52 Europe/Rome, Ruslan Zasukhin wrote:

> First of all I recommend to find and read some book about RDBMS and
> transactions. About Isolation levels 0 - 3.

touché!

after some web search:)

> Transaction isolation refers to the degree of interaction between 
> multiple concurrent transactions.
> SQL-92 defines four isolation levels, all of which are supported by 
> SQLAPI++:
>
> Read uncommitted (the lowest level where transactions are isolated 
> just enough to ensure that physically corrupt data is not read)

is this same as NoLock?

> Read committed

is this same as LockRead + ForwardOnly?

> Repeatable read

is this same as LockRead + RandomMove?

> Serializable (the highest level, where transactions are completely 
> isolated from one another)

is this same as LockWrite?


So we don't have a transaction system yet, but just a cursor lock system

when we'll have transactions doesn't the isolation level set the rules 
over the cursor building lock mode (or we'll have both and the stricter 
will overrid the weaker)?

As I got it however locking should depend on the operation being 
performed other than the isolation level:

Read uncommitted (NoLocks):
• When a row is read the most recent data should be returned even if 
changed
but not yet committed by other transactions
(we don't have transactions yet so this should be irrelevant)
• When a row is edited/deleted no lock is set on it (so better don't do 
that!)

Read committed (Lockread level 1):
• When a row is read a ReadLock must be set on it and released when 
moving on
(so wee could simply set Cursor.CurrentPosition = 0 and release all 
locks),
the most recent data should be returned even if changed
but *only* if committed by other transactions
(we don't have transactions yet so this should be irrelevant)
• When a row is edited/deleted a WriteLock must be set on it and 
released when done

Repeatable read (Lockread level 2):
• All the cursor is ReadLocked
and no other cursor or transaction can edit it's records
so we can move back and forth in the cursor
and be sure to find always the same data
• When a row is edited/deleted a WriteLock must be set on it and 
released when done

Serializable (LockWrite)
• All the cursor is locked for write
no one else can even read it


I think this way we have full security options
and as much flexibility as we can get
and forget my request of manual locking
since it would be handled as needed by kernel
based on the operation and Isolation setting



Cool Runnings,
Erne.

|er| musical box
|ne| a media store