NoLocks // 1.9.8b10 adoption of record locks. Feedback

[Ruslan Zasukhin]

on 7/6/03 20:37, erne at ernestogiannotta at tiscalinet.it 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

Aha, I see your point,
But then WHY you want have separate call?

> 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

Okay. As I have told for now was implemented SIMPLEST record locking which
must give us safety for multi-user access and do not break existed code too
much.

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