NoLocks // 1.9.8b10 adoption of record locks. Feedback

[erne]

Hi Ruslan,

On Lunedì, lug 7, 2003, at 16:26 Europe/Rome, Ruslan Zasukhin wrote:

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

I'm sorry to be pedantic as usual,
but I can't see this Read committed behaviour in current implementation

we have only a ReadLocked cursor (Repetable read) that isn't able to 
write
and won't let any others do it
(well only if we have set ForwardOnly but in that case we don't have a 
true scrollable cursor and we need to visit that record to set it free 
anyway)

is it planned for future betas?

I ask because this mode seems to me the easiest and preferable one
to convert my existing apps in fairly secure network ones
(i.e. let me use cursors as dynamic, modern, fast, in a word cool data 
storage :)


Cool Runnings,
Erne.

|er| musical box
|ne| a media store