NoLocks // 1.9.8b10 adoption of record locks. Feedback

[erne]

Hi Ruslan,

On Sabato, lug 5, 2003, at 22:08 Europe/Rome, Ruslan Zasukhin wrote:

>
>> yep! I could fine tune the timing of calls inside loop in my code also
>> but having it built in db kernel is fine indeed
>>
>> the question remains though:
>> How different is this from calling locks manually?
>
> Easy.
>
> Let cursor selects million of records.
>
> In our way, NOTHING is sent on network to do lock of million of 
> records.
> They will be locked by server.
>

maybe I don't get it,
but seems to me that we're sending a SQL request on the network for that

> In manual way, you will need send million calls via network
>

Let cursor selects million of records.
res = cursor.LockWrite
would be an atomic call asking the server to lock all that cursor's 
records
and not a million calls

but if i need only modify a single record I could call
res = cursor.LockRecordWrite
and still get to modify 1 record without having to kill my million recs 
cursor
or, worst, lock million records to edit just 1

of course if cursor is readonly I may be still able to
cursor = SqlSelect(ThoseFields)
or
SqlExecute(EditThatField)
without having to kill that million cursor

this is what my NoLocks request was about
and where the need of a Change event notification arise
currently this works fine because cursors are pointing to BO data
(though a little trick is necessay in V4RB: you must use 
cursor.CurrentRecord to force the field.value to update)

All my arguing is still about keeping on using cursors as cool data 
storage other than simply retrival tools

I'm also afraid that having to release the cursors ASAP
could lead to intensive use of new queries in code
eventually clogging the system even more than necessary



Cool Runnings,
Erne.


|er| musical box
|ne| a media store