Session within a session lock?

I have a page on my PHP site that needs to access itself. I open a
socket connection and pass in the HTTP request header including a cookie
string such as:

Cookie: PHPSESSID=766bc531e9185be6b54206c944f258d9

With the session name and id of the user's current session (as I want
the request to the web server to utilize the same PHP session). However,
if I use the same session ID things seem to lock and the fread's from
the socket just don't return any data. Why would there be a lock in
doing a request within a request to the same PHP session?

Thanks,
Steve

Steve Wardell wrote:

> I have a page on my PHP site that needs to access itself. I open a
> socket connection and pass in the HTTP request header including a cookie
> string such as:
>
> Cookie: PHPSESSID=766bc531e9185be6b54206c944f258d9
>
> With the session name and id of the user's current session (as I want
> the request to the web server to utilize the same PHP session). However,
> if I use the same session ID things seem to lock and the fread's from
> the socket just don't return any data. Why would there be a lock in
> doing a request within a request to the same PHP session?

The original request probably still has the session file open, waiting
until the end of the script to write the new session files and then
close it.

Try using session_write_close() before making this other request. That
means you won't be able to change the session values after the request
though (unless you can issue session_start() again??)

This whole "method" you've got going on here seems really suspect, but I
guess that wasn't your question... :)

--
---John Holmes...

Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/

php|architect: The Magazine for PHP Professionals – www.phparch.com

--- Steve Wardell <steve@team.bantu.com> wrote:
> I have a page on my PHP site that needs to access itself. I open a
> socket connection and pass in the HTTP request header including a
> cookie string such as:
>
> Cookie: PHPSESSID=766bc531e9185be6b54206c944f258d9
>
> With the session name and id of the user's current session (as I want
> the request to the web server to utilize the same PHP session).
> However, if I use the same session ID things seem to lock and the
> fread's from the socket just don't return any data. Why would there
> be a lock in doing a request within a request to the same PHP session?

Yep, and it makes sense if you think about it. Apache is busy tending to your
first request, and it hasn't returned yet. PHP isn't going to let other stuff
come in and change the session until it writes to it. Now this second request
comes along and wants to access the same session data store. Be glad that such
synchronization issues are handled for you.

Rather than trying to work around this, I would suggest ditching this method
completely. It is very ugly. :-)

Chris

=====
My Blog
http://shiflett.org/
HTTP Developer's Handbook
http://httphandbook.org/
RAMP Training Courses
http://www.nyphp.org/ramp

Thanks guys. Makes sense. This is a conversion from ColdFusion and was
not an issue in ColdFusion, thou in CF you could do read or write
locking to allow for such situations. I'll rework things.

Steve

John W. Holmes wrote:

> Steve Wardell wrote:
>
>> I have a page on my PHP site that needs to access itself. I open a
>> socket connection and pass in the HTTP request header including a
>> cookie string such as:
>>
>> Cookie: PHPSESSID=766bc531e9185be6b54206c944f258d9
>>
>> With the session name and id of the user's current session (as I want
>> the request to the web server to utilize the same PHP session).
>> However, if I use the same session ID things seem to lock and the
>> fread's from the socket just don't return any data. Why would there
>> be a lock in doing a request within a request to the same PHP session?
>
>
> The original request probably still has the session file open, waiting
> until the end of the script to write the new session files and then
> close it.
>
> Try using session_write_close() before making this other request. That
> means you won't be able to change the session values after the request
> though (unless you can issue session_start() again??)
>
> This whole "method" you've got going on here seems really suspect, but
> I guess that wasn't your question... :)
>