|
|
Posted by Jerry Stuckle on 05/23/06 06:09
rich wrote:
> (First of all, one client cannot generally access the session data of
> another
> client. You'd have to have some special handling in there.)
> If you put it in a table they can right? If you do this can't you use
> the session_set_save_handler(write) function at all instances when you
> write to the session to write the data to the table? I see what you
> mean by the problem with the session time out, but can't this time be
> put in like 5 mins. If you are idle, it destroys the session? I am
> pretty new to this. Thanks for your input.
>
Yes, if you put it in a table. That's what I meant by special session handling.
However, the rest of the comments stand. Data is not necessarily sent to the
session handler when you do something like $_SESSION['recid'] = 123; It can be
queued by PHP until some later time. So just because you've set the parameter
doesn't mean it's in the table.
Same thing when you clear the session. The request is not necessarily sent to
the session handler immediately.
The bottom line is - you can expect all kinds of problems if you try to use
sessions to lock rows or otherwise stop concurrent access to a resource. The
timing will get you sooner or later.
And BTW - ok, so you do set the session timeout to 5 minutes. You bring up a
screen. User fills out most of the data. Then he has to get some info from the
guy in the next cubicle, someone on the phone - or maybe he just gets a phone
call. Suddenly his 5 minutes have expired and he's got to start all over again.
The bottom line is - you should NEVER lock a resource (especially one or more
rows in a database) while waiting for user input.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|