I am working on some AJAX callbacks. These need to open the session, get hold of stuff in $_SESSION
and that is it ... they won't be changing the session data. The trouble is that because the
session file is locked the Asynchronicity of AJAX is reduced a bit, especially if some of the
server side calls need a lot of work.
May I suggest:
session_disconnect();
This would, in effect, close the session file but leave $_SESSION. This would be easy to implement,
just call the second callback to session_set_save_handler().
This is NOT quite the same as a session_end() function since that would presumably write the
(changed) contents of $_SESSION back to where ever. With session_disconnect() any changes made
to $_SESSION would be lost regardless of them being made before or after the call to session_disconnect().
Another way of doing this would be to add an optional boolean argument to session_start() which
would load $_SESSION and then disconnect. This is more intrusive in that changes to any user
open functions (of session_set_save_handler()) would be needed. It might be a tiny bit faster
or neater.
I do not know how much of a speed improvement this would make to what sort of AJAX applications.
Regards
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
There is no function needed if you use http://php.net/manual/de/function.session-write-close.php
like others do since ten years :-)
if you know that you no longer write to the session use it
this does not mean $_SESSION is lost
it means only that changes to $_SESSIOn are not available for other requests
Am 16.05.2011 15:37, schrieb Alain Williams:
I am working on some AJAX callbacks. These need to open the session, get hold of stuff in $_SESSION
and that is it ... they won't be changing the session data. The trouble is that because the
session file is locked the Asynchronicity of AJAX is reduced a bit, especially if some of the
server side calls need a lot of work.May I suggest:
session_disconnect();This would, in effect, close the session file but leave $_SESSION. This would be easy to implement,
just call the second callback tosession_set_save_handler().This is NOT quite the same as a session_end() function since that would presumably write the
(changed) contents of $_SESSION back to where ever. With session_disconnect() any changes made
to $_SESSION would be lost regardless of them being made before or after the call to session_disconnect().Another way of doing this would be to add an optional boolean argument to
session_start()which
would load $_SESSION and then disconnect. This is more intrusive in that changes to any user
open functions (ofsession_set_save_handler()) would be needed. It might be a tiny bit faster
or neater.I do not know how much of a speed improvement this would make to what sort of AJAX applications.
There is no function needed if you use http://php.net/manual/de/function.session-write-close.php
like others do since ten years :-)
But that writes $_SESSION back. I am looking to optimise the case when you know that there will
be no changes to $_SESSION.
if you know that you no longer write to the session use it
this does not mean $_SESSION is lost
it means only that changes to $_SESSIOn are not available for other requests
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
Am 16.05.2011 15:50, schrieb Alain Williams:
There is no function needed if you use http://php.net/manual/de/function.session-write-close.php
like others do since ten years :-)But that writes $_SESSION back. I am looking to optimise the case when you know that there will
be no changes to $_SESSION.
session_start();
session_write_close();
sorry but for such simple two-liners a own function only without a lock
for one millisecond is really useless
On Mon, May 16, 2011 at 3:41 PM, Reindl Harald h.reindl@thelounge.netwrote:
There is no function needed if you use
http://php.net/manual/de/function.session-write-close.php
like others do since ten years :-)if you know that you no longer write to the session use it
this does not mean $_SESSION is lost
it means only that changes to $_SESSIOn are not available for other
requestsAm 16.05.2011 15:37, schrieb Alain Williams:
I am working on some AJAX callbacks. These need to open the session, get
hold of stuff in $_SESSION
and that is it ... they won't be changing the session data. The trouble
is that because the
session file is locked the Asynchronicity of AJAX is reduced a bit,
especially if some of the
server side calls need a lot of work.May I suggest:
session_disconnect();This would, in effect, close the session file but leave $_SESSION. This
would be easy to implement,
just call the second callback tosession_set_save_handler().This is NOT quite the same as a session_end() function since that would
presumably write the
(changed) contents of $_SESSION back to where ever. With
session_disconnect() any changes made
to $_SESSION would be lost regardless of them being made before or after
the call to session_disconnect().Another way of doing this would be to add an optional boolean argument to
session_start()which
would load $_SESSION and then disconnect. This is more intrusive in that
changes to any user
open functions (ofsession_set_save_handler()) would be needed. It might
be a tiny bit faster
or neater.I do not know how much of a speed improvement this would make to what
sort of AJAX applications.
on a related note, could we fix http://bugs.php.net/bug.php?id=38104 ?
with that in mind, somebody could close and reopen the session
as necessary(with releasing and acquiring the lock properly).
personally I always went with the lock the whole session until the request
is complate, used the session_write_close to release the lock on the session
before the request ended, but never needed to re-open it after I closed.
but I can see why is the current behaviour is a PITA.
Tyrael