You can't really *ENSURE* that a destructor is ever called (it's even defined an anti-pattern in some cases).
The problem here is that your service is shared, therefore your service manager has a reference to it internally. Get rid of the idea of relying on `__destruct()` before digging yourself a grave. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On 17 September 2013 23:59, shinymayhem <[email protected]> wrote: > I'm creating objects with factories using the service manager, similar to > this (simplified), > > public function getServiceConfig() > { > return array('factories'=>array( > 'model'=>function($sm) { > return new Model(); > }; > )); > } > > and returning results with REST, and noticed the destructor isn't called, > at > least for the final iteration, when an ivar is reused for multiple > instantiations. I'm testing the destructor with a file operation. It works > when I call > > unset($this->_model); > > manually in the controller. > I have the same problem for the model's dependencies. The model's mapper is > created by the ServiceManager's factory, but when the model destructs, the > mapper is acting like it still exists. Even when the script exits and PHP > is > finished running, the mapper's destructor is still not called. I am not > calling die() or exit() in any destructors. > > How can I ensure that cleanup is done? > > I can provide more details or a working example if requested. > > > > -- > View this message in context: > http://zend-framework-community.634137.n4.nabble.com/destructors-not-called-tp4660995.html > Sent from the Zend Framework mailing list archive at Nabble.com. > > -- > List: [email protected] > Info: http://framework.zend.com/archives > Unsubscribe: [email protected] > > >
