To view the terms under which this email is distributed, please go to

On 30 November 2004 14:45, SCALES, Andrew wrote:

> Thanks very much for your help. The main difficulty I was
> having really was
> unlocking the record again if the user crashed out or just
> closed down their
> browser/computer (something they have a bad habit of doing)
> but storing the
> time the record was locked and ignoring the lock if it's over
> that time
> sounds interesting.
> I may try storing the data in a session variable and then
> comparing that to
> the database before the updated data is inserted into the
> record as Bastien
> suggested. We wanted to keep hits on the db to a minimum, but
> seen as some
> extra traffic will be necessary anyway I may just try that.

Another approach to this might be:

Keep a column in your database table for time of last update of each record.

When a user reads a record for update, don't lock it at this point, but save
the time at which it was read into the user's session (or somewhere in the

On receiving a potential update, check the time the record was read (as
recorded above) and the last update time of the record (lock the record as
part of this query) -- if the update time is later then the read time,
someone else has updated in the interim and you should abandon ship;
otherwise, update the record including a new last-updated value; in either
case, unlock the record.

This methodology keeps both the lock and unlock in the same script (and
potentially within a single database transaction), so no need for any
external checks for locked records, and minimizes the amount of time for
which any one record is locked.



Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS,  LS6 3QS,  United Kingdom
Tel: +44 113 283 2600 extn 4730      Fax:  +44 113 283 3211 

PHP Database Mailing List (
To unsubscribe, visit:

Reply via email to