ID:               45270
 Updated by:       [EMAIL PROTECTED]
 Reported By:      vesselin dot atanasov at gmail dot com
-Status:           Open
+Status:           Bogus
 Bug Type:         Session related
 Operating System: Fedora Core 8
 PHP Version:      5.2.6
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.

See bug #45380 which has a bit more info.


Previous Comments:
------------------------------------------------------------------------

[2008-07-08 15:16:45] vesselin dot atanasov at gmail dot com

Hello Jani,
Once a PHP process/thread starts a session, it acquires an exclusive
lock of the session variables. This means that a different PHP
process/thread cannot start a session while the first process is
working. This turns out to be a problem for websites that provide some
kind of API. Let's assume that our API has two kinds of calls:
A) Ones that take more or less long time, e.g. 5-10 minutes.
B) Ones that take a sort time, e.g. 1-2 seconds.

So here is what a long web API call should look like:
1. Start the session (acquire an exclusive lock of the session data).
2. Read some session variables.
3. Close the session (release the exclusive lock).
4. Do some long processing for 5-10 minutes.
5. Write the processing result to standard output, effectively sending
it to the client that called the API.
6. Start the session again (acquire the exclusive lock again).
7. Write some state variables back to the session data.
8. Terminate the PHP script.

So from this sequence it is obvious that in step 4 many short API calls
can be performed while the long processing takes place. If we cannot
stop the session, releasing the lock and then start it again, we need to
hold the lock for 5-10 minutes thus serializing access to the API, which
is pretty inefficient.

------------------------------------------------------------------------

[2008-07-08 13:30:31] [EMAIL PROTECTED]

Why would you stop and start a session in same request? It's by design
like this..

------------------------------------------------------------------------

[2008-06-14 14:05:09] vesselin dot atanasov at gmail dot com

Description:
------------
session_start() incorrectly tries to send a cookie even when it has
already been sent. This causes problems with sessions that are closed
with session_write_close() some output has been sent and then the
session is re-opened with session_start()

The second time when session_start() is called it should avoid sending
the cookie and cache headers, since they have already been sent by the
first call to session_start(). It seems that the second time
session_start() tries to send the same cookie value as the first time,
so it should be possible to avoid sending that cookie a second time.

Reproduce code:
---------------
<?php
session_start ();
session_write_close ();
print ("Test");
session_start ();
?>


Expected result:
----------------
No output at all.

Actual result:
--------------
Test
Warning: session_start() [function.session-start]: Cannot send session
cookie - headers already sent by (output started at
/var/medical/htdocs/try.php:4) in /var/medical/htdocs/try.php on line 5

Warning: session_start() [function.session-start]: Cannot send session
cache limiter - headers already sent (output started at
/var/medical/htdocs/try.php:4) in /var/medical/htdocs/try.php on line 5


------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=45270&edit=1

Reply via email to