On 19/02/2006, at 9:21, Jim Ault <[EMAIL PROTECTED]> wrote:
From: >
Subject: Re: File sharing, locking, etc... between multiple users...
To: How to use Revolution <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="US-ASCII"
On 2/18/06 6:39 AM, "Kurt Kaufman" <[EMAIL PROTECTED]> 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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
