File sharing, locking, etc... between multiple users...

Rob Cozens rcozens at pon.net
Sat Feb 18 15:45:46 EST 2006


Hi Kurt:

> Is this how most databases function?
>
>> On further thought on the record locking..
>> It might be possible for you to take the approach that the real field 
>> is
>> never edited real time, but only a temp field that is later processed 
>> in the
>> time sequence (the seconds) 'submitted' in an orderly event loop.  
>> This way,
>> 4 users could be editing the "same field" while seeing that other 
>> users are
>> doing likewise ("chat room style").
>>

I got into this conversation late; so sorry if my remarks are out of 
context.    :{`)

 From my experience the most common type of locking is record locking.  
This can be done on command, usually as a parameter to a database read 
command.  Once locked, the record cannot be modified by any other user 
until it is unlocked--via an unlock command if the record was not 
modified or a parameter to the write command when the record is 
changed.  Some dbs include a parameter to allow/disallow read-only 
access to records locked by other users.

Some dbs support "automatic" locking, where the first client to set 
current position on a record locks that record until the client's 
current position for relative record access (eg: previous,next) in the 
db changes.

Some dbs support file locking, where a client can open a db for 
exclusive use, or restrict all others to read-only access.  This is 
more prevalent in "flat file" databases.

Since fields are generally sub components of records, field locking is 
not practical: one can't effectively lock a field without locking the 
entire record.  Some dbs deal with this by setting authority levels in 
user profiles and specifying the minimum authority for a user to (a) 
view and/or (b) modify individual fields in each record's data 
dictionary.

The actual locking mechanisms vary.  In some dbs, especially older 
non-server multi-user environments, records are locked by actually 
flagging the record and writing it back to the db.  The means:
* a locked record must be rewritten even if it is not changed in order 
to unlock it, and
* records locked at system crash must be unlocked during system recovery

With client/server systems, the server can maintain a locked record 
table in RAM for each database.

Rob Cozens
CCW, Serendipity Software Company

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)




More information about the use-livecode mailing list