#49432 [Opn]: $_SESSION cannot store objects and resources
ID: 49432
User updated by: jost dot boekemeier at googlemail dot com
Reported By: jost dot boekemeier at googlemail dot com
Status: Open
Bug Type: Documentation problem
Operating System: Any
PHP Version: Irrelevant
New Comment:
I think the problem is that PHP currently does not support session
objects which in turn manage external resources or implement
__sleep()/__destruct() for other reasons.
This problem could be fixed by introducing a "Finalizable" tagging
interface. Objects implementing this interface will not be destroyed
before rshutdown, but added to a internal "finalizable_list". This list
is then traversed by the session module to call __sleep() on each object
in the list. After rshutdown the gc will examine the finalizable_list
again and destruct all objects in the list.
That means: Objects implementing the "Finalizable" interface will
receive __sleep() before __destruct(), for all other objects the
behaviour stays the same.
I think this should be easy to implement and won't break existing
applications or libraries.
I will open a new ticket for this.
Thank you very much!
Previous Comments:
------------------------------------------------------------------------
[2009-09-02 14:19:57] colder@php.net
Actually, it a choice we have to make: first destroy objects or first
terminate sessions.
Currently, we first call __destruct on objects, then terminate
sessions.
This has the advantage of allowing objects destroyed at shutdown to
still be able to manage session data.
The only drawback is that __sleep() gets called after __destruct which
you discovered here. So maybe we should add a notice to __sleep's
documentation.
------------------------------------------------------------------------
[2009-09-02 14:01:13] preinheimer at gmail dot com
PHP can store objects in sessions.
http://example.preinheimer.com/sessobj.php
The shutdown order (destruction before serialization) is likely faulty.
Please file a bug against the language for that issue.
------------------------------------------------------------------------
[2009-09-01 22:37:10] jost dot boekemeier at googlemail dot com
> CSD can be obtained, rather than CDS through the use o
session_write_close
A PHP library needs a reliable PHP behaviour. The library cannot force
users to use
or not use session_write_close() to properly write a session.
When __destroy() is called before __sleep(). the library has no other
choice than to
throw an exception telling the user that the object has already been
destroyed by
php. As a result users of the library report a bug to the library
author.
I am trying to avoid these bug reports.
------------------------------------------------------------------------
[2009-09-01 20:20:29] jost dot boekemeier at googlemail dot com
[Please don't take bug reports lightly]
> Objects can in fact be stored in sessions.
No, they can't. See the php demo attached to this ticket.
IF you want to make php objects finalizable, you must introduce a new
api, similar to
Scheme's or Java's weak refs.
> They are serialized fo storage, the __sleep() and __wakeup() magic
methods have
bee
_sleep() is useless as it is called long after the objects have been
nuked.
It's a chicken/egg problem. PHP must call _destruct() before it can
call the session
save handler. Therefore the handler cannot do much with the destroyed
objects
anymore.
------------------------------------------------------------------------
[2009-09-01 19:56:22] preinheimer at gmail dot com
to clarify further.
CSD can be obtained, rather than CDS through the use of
session_write_close().
If you'd like to argue for better documentation on shutdown order, or
the fact that both the destructor and _sleep() are called when the
script ends, that might be fair. But sessions can indeed store objects.
note that X is actually destroyed, You've stored a serialized copy
inside _SESSION, but there's that copy outside session as well, it is
destroyed when the script ends.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/49432
--
Edit this bug report at http://bugs.php.net/?id=49432&edit=1
Thread (9 messages)