Hmmm...that is true....
It would still prevent Jill from editing. I'll probably add a locked_by
field to convey the user info.
For Dead Locks:
A. Browser Closed Before Finishing Edit:
From what I have read Get_Lock locks are automatically released
when connections terminate. I'm new to this so am unsure if MySQL will
terminate the connection when the browser is closed. If not does MySQL
disconnect users after a certain time? And is this a configurable option?
B. User goes to lunch before hitting Submit
I was thinking of putting a timout feature in the browser so that
after say 5 minutes a prompt asking the user that has the record locked if
he is still working or wants to cancel. This popup would have 20 seconds or
so before cancel was automatically selected and the lock is released.
C. User types in www.something.com and leaves the editing page in limbo:
I have no idea what to do in this situation. If MySQL can be
configured to boot a user after so may minutes of activity then that is the
solution. As with possibility A I am unsure.
Sound Feasable?
Rasmus Lerdorf <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > OK that example is poor I admit...but do you see the reasoning behind
> > locking? If a lock was in place Jill would't be able to edit her post
> > because she would get a message stating that Admin Jack was allready
editing
> > it.
>
> GET_LOCK has no way of conveying that information. You would need to use
> a completely different mechanism to identify who is holding a lock.
>
> How are you going to avoid deadlock?
>
> -Rasmus
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
