NoLocks // 1.9.8b10 adoption of record locks. Feedback

[erne]

on 4-07-2003 21:03, Ruslan Zasukhin at sunshine at public.kherson.ua wrote:

>> Ruslan says that manual locking could result in a server under assault from
>> small clients' requests but I still don't see no difference in current
>> approach... clients will still have to issue multiple queries for their
>> cursors in a tight loop hoping to find a hole to slip their request in
>> 
>> or maybe I don't understand it well...
> 
> Look,
> 
> In 2.0 we will add feature that when you ask for some cursor and server
> cannot set lock(s) this task will go sleep on some time, and later will try
> again.
> 

and my app what is supposed to do in the meantime?
of course show some "Please wait..." message

> This will be continued e.g. 5 seconds.
> In case server was not able set locks for this 5 seconds, you get the same
> error CannotSetlocks.
> 
> So your current sources still will work, just loop will be not so tight.
> 

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?

But mine may be a simply semantic arguing
as long as we can have a read only cursor alive (with NoLocks) and can call
a write enable cursor with the record we need the result is substantially
the same
i.e.
We manually lock for write just the record we need while keeping the
browsing cursor alive
it just lives in another cursor

my proposal of a cursor.LockRecordWrite function would just be more simple
to code 
(Valentina could handle the real work under the hood
 i.e. build the writable Cursor and give it to us transparently...
 we're sooo lazy 8-)

mmm... I see the issue is in the update of data

from other post:
>>> Thinking about how Filemaker Pro handles this, (if I'm not mistaken),
>>> you can always read any record and it will show you the last modified
>>> state. (It will automatically notify other cursors of changes.)
> 
> I have explain that this is bad idea to notify all cursors on changes.
> Only DB Server with small number of users can allow to self do this.
> 

what if we plan to serve small network (say 1 to 20?)
is Valentina aimed only at large corporate or web serving?


some dumb questions:
what's the price of notify cursors of changes?
huge overhead? system clogging?

as things stand now
what's the way to know our local data are no more up-to-date?

i = SqlExecute("Update t set f = 'hi' Where recid = 1")
will fail if recid 1 is locked somewhere?
i.e. i = 0 and db.Error = CannotSetlocks

and what if
i = SqlExecute("Update t set f = 'hi' Where f = 'ho'")
and we have 10 records with f = 'ho'
will fail if just 1 of the satisfying records is locked somewhere?
i.e. i = 0 and db.Error = CannotSetlocks
or we get i = 9 and db.Error = 0 ?
(ok I know it must be i = 0)


sorry if I bother so much
(mostly out of deep ignorance ;-)


Cool Runnings,
Erne.

-- 
|  e r  |  Ernesto Giannotta
|  n e  |  Musical Box - a media store