#49432 [Opn->Bgs]: $_SESSION cannot store objects and resources

From: Date: Fri, 13 Nov 2009 22:25:45 +0000
Subject: #49432 [Opn->Bgs]: $_SESSION cannot store objects and resources
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-3147@lists.php.net to get a copy of this message
 ID:               49432
 Updated by:       vrana@php.net
 Reported By:      jost dot boekemeier at googlemail dot com
-Status:           Open
+Status:           Bogus
 Bug Type:         Documentation problem
 Operating System: Any
 PHP Version:      Irrelevant
 New Comment:

Already documented at http://www.php.net/manual/en/intro.session.php:
"Some types of data can not be serialized thus stored in sessions. It
includes resource variables"


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

[2009-09-02 15:54:13] jost dot boekemeier at googlemail dot com

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!

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

[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.

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

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)

« previous php.doc.bugs (#3147) next »