StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POWriting to Zend_Session_Namespace in destruct
text
Body
copied!<p>I'm noticing some slightly unexpected behaviour using <code>__destruct</code> to write data using <code>Zend_Session_Namespace</code> in PHP 5.3:</p> <pre><code>public function __destruct(){ $this->getSession()->data = $this->data; } // .... private function getSession() { if (! self::$zendSession) { // this next line is fine because the object is a singleton self::$zendSession = new Zend_Session_Namespace(self::SESSION_NAMESPACE); } return(self::$zendSession); } </code></pre> <p>The destructor is getting called, but the data isn't getting written. However, if I implicitly call the destruct after the object has had all the necessary operations done on it, and force destruction before script termination, the data is written fine, but I'd rather not do this.</p> <p>I imagine it has something to do with this bug: <a href="http://bugs.php.net/29032" rel="nofollow">http://bugs.php.net/29032</a> (bug seems a bit old to me), and on the face of it the fix looks good (register __destruct as shut-down function, which is called before <code>$_SESSION</code> is unavailable), but wouldn't the destructor get called twice (once through the <code>register_shutdown_function</code> and once automatically?</p> <p>Surely writing the odd bit of object data to session on shutdown is a thing that has been solved? What do people do when this is required?</p> <p>(OSX 10.6.6, Apache 2.2.15 (Unix), PHP 5.3.3, Zend Framework 1.7.2)</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload