> Date: Wednesday, November 30, 2016 08:31:43 -0500 > From: Tedd Sperling <tedd.sperling@xxxxxxxxx> > >> On Nov 29, 2016, at 2:09 PM, Stuart Dallas <stuart@xxxxxxxx> wrote: >> >> On 29 November 2016 at 16:51:24, Tedd Sperling >> (tedd.sperling@xxxxxxxxx) wrote: >>> <snip> >> As mentioned I’m pretty sure this is because you’re attempting >> to lock in one request and expect the lock to still be there in >> subsequent requests. This is fundamentally not how MySQL table >> locks work so you’ll need to implement your own mechanism. >> < snip ... > > > What about using a “busy” Table? I imagine it would work like > this: > > Let’s say a user accesses a page that allows editing of Tables A, > B and C. However, before editing is permitted, the script checks > the “busy Table” to see if those Tables (A,B,C) are currently > being used. > > If the Tables are not busy, then they are marked “busy" and the > user is permitted to edit. > > When the user finishes editing (i.e., leaves the page), then the > script marks Tables A,B,C as "not busy”. > > The process goes for all users — each script checks the busy > Table to see if the Tables needed for their operation are in use. > If the tables are open, then editing is permitted, if not then the > user is denied and notified. > Explicitly or implicitly locking tables, or even records, will run you into trouble. Locking tables is a very heavy hammer and will keep everyone else from doing updates -- even on unrelated records. Locking at either level runs into the problem of things being locked even when the locking user has gone on to other things -- in a different window or room -- and not taken the action necessary to release the lock. 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. A somewhat related example of this is the github forums. If you are composing a response and a new response is submitted before you complete yours, your screen is updated so you see the new response (and so can adjust what you are writing accordingly). This isn't exactly analogous to your environment, but it gives an idea of one way to handle this type of situation. 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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
