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