I don't think get_lock will work here anyway since the only way to
use it is with persistent connections, and there's no guarantee the
person will get the same connection with the second request, he
probably won't. without persistent connections the lock will die when
the script finishes.
On Fri,
On 06-Oct-2001 Chip wrote:
>> Well, if you only update the fields that changed then who cares? The
>> fields that Jill changes are going to overwrites Jack's changes anyway.
>> Locking the record and having Jack finish before Jill can start isn't
>> going to change the end result which would be
> So once a user logs into a MySQL Server via PHP, if they don't logout, they
> stay logged in forever???
Depends how you write your application. If you are using persistent
connections you log in and out of mysql durig a single request. If you
use persistent connections you log in once and
So once a user logs into a MySQL Server via PHP, if they don't logout, they
stay logged in forever???
Rasmus Lerdorf <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > A. Browser Closed Before Finishing Edit:
> > From what I have read Get_Lock
> 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
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
> 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
> Well, if you only update the fields that changed then who cares? The
> fields that Jill changes are going to overwrites Jack's changes anyway.
> Locking the record and having Jack finish before Jill can start isn't
> going to change the end result which would be that Jill's changes are
> going
> 1. Jack opens record A to change an entry.
> 2. Jill opens record A to change an entry.
> 3. Jack finishes his changes and saves the data.
> 4. Jill finishes her changes and saves the data.
Well, if you only update the fields that changed then who cares? The
fields that Jill changes are going
Well here is the situation.
1. Jack opens record A to change an entry.
2. Jill opens record A to change an entry.
3. Jack finishes his changes and saves the data.
4. Jill finishes her changes and saves the data.
Jill just over wrote whatever Jack did. The only method I could think of to
prevent
It is really a bad idea to design a system where locking is required. Are
you sure there is no way to build the system to not require locking
through the use of atomic updates and such?
Anyway, yes, GET_LOCK is just another query as far as PHP is concerned.
You can pass it to MySQL via mysql_que
11 matches
Mail list logo
