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

[David Vaughan]

On 19/02/2006, at 9:21, Jim Ault <JimAultWins at yahoo.com> wrote:

> From: >
> Subject: Re: File sharing, locking, etc... between multiple users...
> To: How to use Revolution <use-revolution at lists.runrev.com>
> Message-ID: <C01CC74E.34DEB%JimAultWins at yahoo.com>
> Content-Type: text/plain;	charset="US-ASCII"
>
> On 2/18/06 6:39 AM, "Kurt Kaufman" <kkaufman at snet.net> wrote:
>>
>>> 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").

Many years ago there was a database which operated in a manner  
similar to Kurt's description; Dataflex. The theory was that a record  
was not locked until you actually tried to commit your edit. At this  
point, it would be locked and re-read from the database, and if it  
did not match the previously cached read then the write did not occur  
and it was up to the programmer (and user) to resolve the situation.   
The advantages were allowing multiple readers and sheer speed given  
it used a file locking rather than record locking method -- the file  
was locked for only a fraction of a second.

Taking Jim's examples:
> Thus, only one edit at a time.  Imagine two ticketing agents for an  
> airline
> selling the last first class seat for a flight in few weeks to  
> different
> people, one agent in New York, another in Paris.  Record locking  
> prevents
> this.
The Dataflex approach meant that both clients would be told the  
flight was available until one of them actually laid their money  
down. Otherwise, one client may be told the flight had gone when in  
fact the other then changed their mind and left it available. If you  
paid too late and lost the flight, too bad; that's commerce.
>
> Another dilemma would be if a third person asked the database for  
> the value
> of a field that was in the process of being edited... What value do  
> you
> report to that third person?
The value currently in the database because no-one has committed a  
change, and edits might yet be cancelled.
>
> Then add to that, a field that was allowed to be edited by two  
> different
> users, neither of which was done with the edit.  Which version is  
> correct?
> Which version replaces the other two?
This was Dataflex's biggest problem in this method, where two users  
read, one writes and the second attempts to write, meaning that the  
second user's edit was on false data. Programmer hell or user  
frustration.

I am not advocating the Dataflex approach at all. Rather, it was a  
way of getting around the limitation that it (and dBase of the era)  
used file rather than record locking but in our experience it was a  
rather effective method with considerable speed advantages (never  
being told your record is unavailable) for small business  
applications where conflicts were unlikely anyway. Not every multi- 
user solution has to be good for a thousand users, so long as it  
keeps its own integrity.

regards
David