RE: Multi-User Update Problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Thank you both for the advice,
Andy

-----Original Message-----
From: Gryffyn, Trevor [mailto:TGryffyn@xxxxxxxxxxxxxxxxx]
Sent: Monday, 29 November 2004 15:44
To: php-db@xxxxxxxxxxxxx
Cc: Bastien Koert; Andrew.SCALES@xxxxxxxxxxxxxxxxx
Subject: RE:  Multi-User Update Problem


Yeah, all good thoughts.  Someone else had a similar question that I
answered recently (I think it was in private email) and in addition to
the thoughts below, you might also look into recording WHEN the record
was opened (and locked) so you can expire the lockout.  I'd use this in
conjunction with a browser side META REFRESH and a PRAGMA cache expire
command so if the person who opened the record doesn't do anything with
it within 2 hours, their browser auto-refreshes (maybe notifying them
that their session was terminating and if they want to save the work
they've done already) and it unlocks the file.

You could also have a nightly job run that looks for all records locked
over 2 hours ago or something and auto-unlock them (or just have the
script that looks to see if something's locked see if it was over 2
hours ago and ignore the Locked == TRUE tag in the database).


Anyway, the idea is to expire the session and user's cache so that
they'll get a "Warning: Page Expired" making it impossible for them to
update something after 2 hours has passed or something like that.  Also
to free up locked pages on a regular basis or allow people to get into
them again if they "time out".

-TG

> -----Original Message-----
> From: Bastien Koert [mailto:bastien_k@xxxxxxxxxxx] 
> Sent: Monday, November 29, 2004 10:22 AM
> To: Andrew.SCALES@xxxxxxxxxxxxxxxxx; php-db@xxxxxxxxxxxxx
> Subject: RE:  Multi-User Update Problem
> 
> 
> Its a tough one. My personal fav is to mark the record as 
> locked by changing 
> a field called 'locked' from 0 to 1. Check for this when 
> extracting the 
> record and if is present, alert the user this record is 
> locked (if you want 
> to get fancy you could even track who locked it and the tell 
> the user that) 
> and show a non-updatable form of the page (either with the fields as 
> readonly or by creating some kind of view only page where the 
> data is simply 
> echoed out). If you want to get REALLY out there, you could track who 
> requested the locked record and notify them when it was 
> released(by the 
> original requestor submitting the form). The possibilities are endless
> 
> The other option is to create/write an entire concurrency 
> module that will 
> store the record in a separate entity (another table or 
> session object)  and 
> then compare any changes made upon submission. I have seen 
> this but I don't 
> really like it, since the ultimate choice is left to the user 
> as to what 
> data is correct.
> 
> 
> 
> Bastien
> 
> >From: "SCALES, Andrew" <Andrew.SCALES@xxxxxxxxxxxxxxxxx>
> >To: php-db@xxxxxxxxxxxxx
> >Subject:  Multi-User Update Problem
> >Date: Mon, 29 Nov 2004 11:16:08 -0000
> >
> >Hello,
> >
> >Does anyone know a good way of locking out access to a 
> record on a MySQL
> >database when someone has the update page open?
> >The problem is that we have a local intranet site which is 
> accessed by
> >members of different departments. Now at the moment when 
> someone loads the
> >page all of the data is pulled into the form, and then when 
> they submit, 
> >all
> >of that data is passed back to the database, including anything they 
> >haven't
> >changed.
> >
> >What we are trying to avoid is situations where for example 
> someone leaves
> >the form open on their computer and goes away for lunch. In 
> the meantime
> >someone else at a different station makes changes to the 
> form. Then when 
> >the
> >first person comes back from lunch, they submit the form, 
> thereby writing
> >over all of the second person's changes with the old data.
> >
> >Does anyone know of a good way to solve or work around this 
> problem? We 
> >have
> >thought about setting a flag on the database whenever 
> someone pulls down 
> >the
> >data, however if their browser crashes or they shutdown with 
> the window 
> >open
> >then this is going to leave the data locked.
> >
> >Thanks very much,
> >
> >Andy

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [PHP Users]     [Postgresql Discussion]     [Kernel Newbies]     [Postgresql]     [Yosemite News]

  Powered by Linux