On Thu, Dec 01, 2016 at 11:01:20AM -0500, Tedd Sperling wrote: [snip] > > 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. I think you're *far* better off doing your "locking" by record. But this whole sequence is why I've never tried to implement any kind of a scheme like this. The idea of taking a run at a record (after edit), compare content, presenting a "diff", running at a record again, possibly taking another "diff", etc. would be maddening. The repetitive processing of a single record, possibly ad infinitum, would be "cost-prohibitive", not to mention technically unbelievably complex. Imagine that for every "Save" screen, you have to do an "Are you sure?" screen. Also, I'm not in favor of placing edit locks until the user actually wants to *save* the edit. A user can dawdle, answer the phone, play DnD all day after declaring he wants to edit a record and then fetching it. He may even abandon it, a button I often add to screens where edits take place. So I typically only think of locking as occurring while the save process is taking place. If the next guy in line to save the record screws with the data you saved after you're done, only *then* do you have a contention issue. I suspect this is why even database OEMs don't adequately solve this problem. I don't think there really is a solution. There's also a larger philosophical question of "what's the truth" about a record. If there is an "amount" field on a record and the answer is $3.56, that ought to be true for every user who answers the question. So from the viewpoint of that amount field, who edits it, when or how, should be unimportant. Only elements that deal in opinions or the like should be important for contention's sake, and in that case, making room for multiple instances of them is perhaps the better answer. If users contend with each other about the "facts" of a record, then there are larger problems involved than just record or table locking. Paul -- Paul M. Foster http://noferblatz.com http://quillandmouse.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
