Paul M Foster wrote:
On Wed, Jul 07, 2010 at 10:01:05PM -0400, Bastien Koert wrote:
On Wed, Jul 7, 2010 at 8:47 PM, Paul M Foster <paulf@xxxxxxxxxxxxxxxxx>
wrote:
On Wed, Jul 07, 2010 at 12:59:30PM -0400, tedd wrote:
Hi gang:
I have *my way* of handling this problem, but I would like to hear
how you guys do it.
Here's the problem -- let's say you have a database containing names
and addresses and you want "approved" users to be able to access the
data. As such, a user must login before accessing an editing script
that would allow them to review and edit the data -- nothing
complicated about that.
However, let's say you have more than one user accessing the editing
script at the same time and you want to make sure that any changes
made to the database are done in the most efficient manner possible.
For example, if two users access the database at the same time and
are editing different records, then there's no real problem. When
each user finishes editing they simply click submit and their changes
are recorded in the database. However, if two (or more) users want to
access the same record, then how do you handle that?
Use a DBMS? I'm sorry if that seems flippant, but a DBMS handles this by
queuing the requests, which is one of the advantages of a client-server
DBMS.
So maybe I don't understand your question.
Paul
--
Paul M. Foster
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
@Paul,
The OPs question is about concurrency on the record itself. How to
avoid two users accessing the same record and potentially damaging
each others changes
My approach is the same as Rob's. Flag it locked and let the second
user gets a read only copy
I can't think of a way to do this using MySQL or PostgreSQL. And one of
the biggest issues with the solution you suggest is the user who opens a
record for writing and then goes out for coffee. Everyone's locked out
of the record (for writes) until they come back and finish.
Okay, to solve that, we start a timer. But when the locker's time is up,
how do we let the locker know they're not allowed to store whatever
edits they've made? And how do we fix it so that those locked out are
now unlocked? Plus, they're probably in a queue, so we really only let
one of them know that they can now make edits.
Since this is a PHP list, I assume we're talking about a web interface.
So how do we do all this back end jockeying? Javascript is about the
only way. But every time you fire off one of these javascript dealies,
it has to be on its own timer so that it can let the user know that the
original locker is gone and now the golden ticket is yours. It
essentially has to sleep and ping, sleep and ping. Actually, it's more
like a spinlock. But a spinlock would eat CPU for every user, if it was
running on the server. So it would have to be running on the client, and
"ping" the server every once in a while.
Then you'd have to figure out some kind of messaging infrastrucure for
the DBMS, so that it would quickly answer "pings" without tying up a lot
of CPU cycles. It would have to be something outside the normal query
infrastructure.
When you actually get into this, it's an incredibly complex solution. I
vote instead for allowing edits to be queued, log changes to the
database. If there is a true contention problem, you can look at the
journal and see who made what edits in what order and resolve the
situation.
The best analogy I can think of is when using a DVCS like git, and
trying to merge changes where two people have edited the same area of a
file. Ultimately, git throws up its hands and asks a human to resolve
the situation.
Bottom line: I've heard about concurrency problems since I started using
databases, and I've never heard of a foolproof solution for them that
wasn't incredibly complex. And I don't think I've ever seen a solution
in actual practice.
If I'm wrong, someone show me where it's been viably solved and how.
I think you're overthinking the issue. The timer handles the issue of
holding onto a lock for too long. As for a write queue... don't bother.
If a user finds that another user has a lock then tell them when it
expires. They can come back and try for the lock on their own. You can
set up AJAX polling to see if the lock has been removed and indicate
this to the user (if they've bothered to wait on the page) but this is
optional. Queuing edits is not a good solution. Imagine document X:
UserA requests X
UserB requests X
UserC requests X
UserD requests X
UserA modifies X and saves X.1
UserB modifies X and saves X.2
UserC modifies X and saves X.3
UserD modifies X and saves X.4
In this scenario all the work done by UserA, UserB, and UserC is
clobbered by the submission by UserD. This can be resolved via merging
such as used by versioning systems, but this makes less sense in a high
traffic collaborative content system such as a wiki. In the lock
scenario we have the following:
UserA requests X
UserA modifies X and saves X.1
UserB requests X.1
UserB modifies X.1 and saves X.2
UserC requests X.2
UserC modifies X.2 and saves X.3
UserD requests X.3
UserD modifies X.3 and saves X.4
At each write step the previous work is appropriately integrated. This
is the desired functionality for a collaborative document such as a
Wiki. In the case of source code, once generally expects a much smaller
number of editors or that editors are working on very different areas of
the source file and so conflict resolution is less common due to
automatic merge by the version control system.
Cheers,
Rob.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
