On Wed, 2006-05-24 at 02:19, Stut wrote:
> Lester Caine wrote:
> > The double click 'problem' was a sideline to the original problem, which
> > I found while trying to track things. The original problem *IS* that PHP
> > can run two copies of a script in parallel and the second copy does NOT
> > see the 'locking' in place on the first copy. I had always thought that
> > PHP was sequential, but I'm not so sure now.
> >
> > I've put in a trap for the double click ( and yes it *IS* browser
> > dependent ) and that works fine, but we will have to see if it makes any
> > difference to the original 'race' problem :(
>
> PHP is not 'sequential' and I have no idea where you got that
> impression. If the browser puts in a request to the server, the server
> will execute that request as soon as sufficient resources are free to do
> so. PHP does not 'lock' the session between requests. This is a problem
> being found by people trying AJAX with a session. Consider this sequence...
>From the manual at:
>
> 1) User hits your button (ooh-err)
> 2) PHP starts processing the script and runs session_start() which loads
> the session data
> 3) User hits your button again
> 4) PHP starts processing the script a second time before the first run
> has finished, and loads the session data again for this new request
> 5) The execution started in 2) ends and commits the session data back to
> the session store
> 6) The execution started in 4) ends and commits the session data back to
> the session store
>
> There are 2 different issues here. First is that the second run will not
> get any changes made in the first run. Second is that any changes made
> in the first run will be lost when the second run commits the session to
> the store. This is a fact of the stateless nature of HTTP and you need
> to plumb around it. There are various ways you can do this. I'm the
> first to admit that I haven't found an ideal solution yet, but methods
> I've used in the past have been...
>
> * Before start_session() check a directory for the existence of a file
> named after the session id. If it doesn't exist call start_session() and
> touch the lock file. Delete the lock file at the end of the request
> (ideally using register_shutdown_function).
>
> * Use shared memory to store an array of session ids that are locked.
>
> Neither of these were ideal because there was a race condition where two
> requests could check the lock at the same time and then both lock it.
>
> Now that I come to think about it again it may be possible to write a
> custom session handler that blocks reading of session data that's been
> locked until it's either unlocked or a timeout passes. You'd have to try
> that to see if it's possible - I'm not sure how the internals of
> session_start() work.
>
> Hope that early morning ramble helps you out.
>
> -Stut
>From the manual at:
http://ca3.php.net/manual/en/function.session-write-close.php
"Session data is usually stored after your script terminated
without the need to call session_write_close(), but as
session data is locked to prevent concurrent writes only
one script may operate on a session at any time. When using
framesets together with sessions you will experience the
frames loading one by one due to this locking. You can
reduce the time needed to load all the frames by ending the
session as soon as all changes to session variables are done"
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
