> 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 _______________ tedd sperling tedd@xxxxxxxxxxxx -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
