> Date: Thursday, December 01, 2016 11:01:20 -0500 > From: Tedd Sperling <tedd@xxxxxxxxxxxx> > >> On Nov 30, 2016, at 9:04 AM, Richard >> <inbound-lists-php@xxxxxxxxxxxxxxxxxxxxx> wrote: >> >> I think a better approach, which Stuart mentioned, is to check for >> changes before writing the update. If no change (based on >> last-modified timestamp (on the record(s) being updated), or record >> hash) then process the update. If things have changed, then give a >> way for the person with the now-stale record to recover. Using ajax >> to notify someone who is editing a record that things have changed >> (before they submit the update) can make this cleaner. >> <snip> >> In a stateless (or even stateful) user environment locks are very >> hard to manage and will often be serious overkill and simply get in >> the way of users getting things done. I would avoid them and manage >> things from the "update" side. > > That seems to makes sense. But let me recap to see if I have this > checking procedure right: > > When a user accesses records, then a timestamp is placed on those > records. > > When the user is finished editing and wants to “Save”, the > script looks at those records and determines if the timestamp have > changed. > > If the timestamp has not changed, then the user can save the data. > > If the timestamp has changed, then stop the user from saving > (overwriting the record) AND present the user with a way to resolve > any differences between what data the user has and what data the > current record now shows. > > After the user reviews/resolves the differences and wants to Save, > then repeat the checking procedure. > > Is that it? > > That doesn’t address the problem raised when two users are > editing the same data at the same time for neither can see what the > other is doing. > > For example: > > User A accesses the record and establishes a timestamp. > User B accesses the same record and establishes a newer timestamp. > User A tries to save, but can’t — AND -- there are no newer > data for User A to inspect to resolve differences. The fact is, > until User B saves the data, user A is in a LOCK condition — is > he/she not? > > Two Questions: > > 1. How does your method deal with the problem presented above? > > 2. How does prohibiting a user from saving data via timestamps > differ from LOCKing* tables? > > * My term “LOCKing" is not via a MySQL LOCK, but rather marking > tables as busy. This does not mean that other user’s cannot > inspect/read the data during a "table busy" condition, but rather > they cannot not save data until they find the table open (i.e., not > busy); refresh (i.e., get newer data and resolve any differences); > install their own busy lock; and finally edit and save their data. > > Many thanks for your time, consideration, and advice. > > Cheers, > > tedd In this scenario, the timestamp is simply the "last modified" timestamp in the database on the record(s) that are being touched. Nothing is explicitly set when someone opens the record for edit. Hence there is no lock or deadlock (of the likes you describe). [that timestamp is part of the data pulled to the browser and then checked on update submission.] If you are going to have many people doing heavy record modifications, so that it's likely that there will be frequent write collisions on the same *record*, then you may need to do more to alert a second person that someone is already editing the record they want to touch. Also, think of all this at a record, not table, level. [please do no include my direct address in replies.] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
