NoLocks // 1.9.8b10 adoption of record locks. Feedback

[erne]

Hi List

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

>> So what does NoLocks do?
> 
> Cursor with NoLocks simply IGNORE all above rules.
> As result even if one cursor lock some records, never mind how, RO or RW,
> Second cursor with NO LOCKS parameter still will be able use that records.
> 
> YES!!! DANGER WAY.
> Should be used very rarely and carefully, Better for reading only.
> 

yep! I see this can be aweful!

other post:

>> You will get nil cursor and ERROR: CannotSetLock.
> 
> Am I understanding correctly above that the second request for 9
> records is Read Only? Hmmm, that could really tie things up. One record
> in Write mode could hold up reading loads of records. What does an
> application, or user, do while waiting for records?!
> 

seen from the other side, if one cursor is used for browse purposes in read
only lock mode it can prevent the writing of a single record for hours!

this way the use of cursors will be reduced to a take-the-data-and-run mode
i.e.
you MUST release the cursor ASAP to avoid the entire system to be clogged up

> Just thinking out loud...
> I wonder if there is a logical way to time-out a cursor of locked
> records, and possibly cue requests for records? Does this make any
> sense? Any ideas?
> 

you mean a cursor being released by a timeout while you're dealing with it?
of course not!
cues is way more civil and preferable behaviour :-)

I don't see though how these could be organized, sure a limit of mine

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

> 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.) It will
> simply not allow two users to modify (be in Write mode on) the same
> record. That is a much more livable process. Is this what Valentina
> does, or can we have it do that?

maybe noLocks should behave this way
i.e. same as readonly but let others lock its records for change
as opposed to ReadOnly lock which ensures data are not changed behind your
back while you are browsing them

I still think that this approach and the possibility to manual lock/release
cursors even on a single record basis would permit much more flexible
designs (of course leaving to those who want/need to be more strict the use
of the current approach)



Cool Runnings,
Erne.

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