NoLocks // 1.9.8b10 adoption of record locks. Feedback

[Ruslan Zasukhin]

on 7/7/03 14:09, erne at ernestogiannotta at tiscalinet.it wrote:

> 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?

Yes. 
 
>> Read committed
> 
> is this same as LockRead + ForwardOnly?

Not exactly but close.
ForwardOnly -- is OPTIMISATION feature only. Nothing more.
It do not set up own level of isolation.

>> Repeatable read
> 
> is this same as LockRead + RandomMove?

Yes. 

>> Serializable (the highest level, where transactions are completely
>> isolated from one another)
> 
> is this same as LockWrite?

Yes.


> 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)?

With SQL92, we will be able control this locks via SQL itself.
So we will be able do

    db.SqlSelect( "SELECT .... Isolation level Read committed" )

And skip that 3 parameters.

> 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!)

yes

> 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

Correct. Isolation level will resolve all automatically.

-- 
Best regards,
Ruslan Zasukhin      [ I feel the need...the need for speed ]
-------------------------------------------------------------
e-mail: ruslan at paradigmasoft.com
web: http://www.paradigmasoft.com

To subscribe to the Valentina mail list go to:
http://lists.macserve.net/mailman/listinfo/valentina
-------------------------------------------------------------