I'm not sure table locking is the answer. I'm not talking about concurrency
in the sense of 'simultaneous' updates and selects, but in the sense of an
'open record edit session' that predictably will overwrite the value of a
record that may have been changed, after the edit session began, but before
the edit session is committed.
Martin Fowler's book, "Patterns of Enterprise Application Architecture" (dull name, I know) has an excellent chapter which describes various kinds of locks. The main applicable distinction in your case is whether you want your lock to be Optimistic or Pessimistic, in other words - do you expect that such conflicts will happen frequently, or no?
If you expect conflicts often, make your lock pessimistic: when user A opens ups a record to edit, a flag gets set on the server which prevents user B from modifying the same record. This form of locking is also good when the change process is coarse, and losing edits would be a major inconvenience. In the case of editing a wiki page, you don't want user B to spend 20 minutes modifying a page, only to be told that there's a conflict and they should try again later, wasting all that work. You want them to know ahead of time. Your "beingedited" field in the DB is an example of a pessimistic lock.
If you don't expect conflicts often, or the cost of a conflict is low, make your lock optimistic: when user A and user B both have a record open, the first one to commit wins, and the second one gets an error message. This is an easy one to implement if you version your changes in some way, perhaps by indicating which version a user started with at commit time. CVS works this way, as does my wiki software of choice, Tavi Wiki. For these applications, the cost of a conflict is high (which would indicate that a pessimistic lock might be better), but there is a clean method provided to resolve them when they come up.
------------------------------------------------------ michal migurski- contact info, blog, and pgp key: sf/ca http://mike.teczno.com/contact.html
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
