Beefy Boxes and Bandwidth Generously Provided by pair Networks DiBona
Keep It Simple, Stupid
 
PerlMonks  

Re: Concurrency control in web applications

by etcshadow (Priest)
on Oct 24, 2003 at 22:34 UTC ( [id://302018]=note: print w/replies, xml ) Need Help??

This is an archived low-energy page for bots and other anonmyous visitors. Please sign up if you are a human and want to interact.


in reply to Concurrency control in web applications

First of all, I understand your question, but I'd still say that in most cases it is not worth the bother of addressing. However, it is sometimes worth it, or even necessary.

What I've done, myself, to address this problem is actually to embed the old values in the form as hidden inputs, and then compare them to what is in the DB on submit. Then prompt the user with a sort of diff3-like opportunity to resolve conflicting edits / approve merged edits. This (mind, this is sort of psuedo-code-like, but I think it conveys the idea):

  • addresses the problem
  • doesn't require any kind of cross-form-submission row locking, which would be a real bad idea
  • avoids the problem of zero-diff changes interfering with meaningful changes
  • puts the onus of resolution on the slow-guy

It's actually very similar, algorithmicaly, to how revision control software (like cvs) works... but it's not actually using revision control software, as that is actually targetted towards large text files, not database forms. It goes something like this:

# in the form HTML generating code... my %row = # fetch row from table into a hash foreach my $col (keys %row) { # actually properly escape all of this stuff... I'm just writing it + out sort of short-hand print "<input type=hidden name=original_$col value=$row{$col}>"; } # in the form processing code... assuming that your form values are p +resent in a hash called %form my %row = # fetch row from table into a hash my (%yours,%theirs); # store colums which were updated by you, and col +umns which were updated by some intervening session foreach my $col (map {/^original_(.*)/ ? $1 : ()} keys %form) { if ($form{"original_$col"} ne $row{$col} { # oh no! this column was updated by some intervening session $theirs{$col} = $form{"original_$col"}; } if ($form{$col} ne $row{$col} { # this is a column that *you* edited $yours{$col} = $form{$col}; } } if (!%theirs) { # there were no intervening edits... process the form! DoThing(\%form); } else { # there were edits maid by another user between the time you downlo +aded the form and when you posted the form back print "CONFLICTS!"; # etc let the user know what the deal is }

And then re-display the form, marking it up appropriately. For example, color the inputs in only %yours as blue, the ones in only %theirs as yellow, and for the ones in both %yours and %theirs... make it green if $yours{$col} eq $theirs{$col} (you made it the same thing... yellow and blue make green!), and make it red if $yours{$col} ne $theirs{$col} (you made conflicting changes... red = bad, warning!). If you want to be super cool... you can even pass the values contained in any textareas through to diff3 (or merge)!

Seriously... I've done this... it's super cool. :-D


------------
:Wq
Not an editor command: Wq

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://302018]
help
Sections?
Information?
Find Nodes?
Leftovers?
    Notices?
    hippoepoptai's answer Re: how do I set a cookie and redirect was blessed by hippo!
    erzuuliAnonymous Monks are no longer allowed to use Super Search, due to an excessive use of this resource by robots.