On Mon, Jun 6, 2011 at 5:31 PM, Richard Quadling <rquadl...@gmail.com> wrote: > Not an internals expert, but I do have a question. > > When would the session handler object be destroyed? > > If sessions are being logged to a DB (maybe via a userland PHP class), > is internal reference counting enough to handle the order of > destruction? > > If the DB connection is destroyed before the session handler gets it > destructor called (or the session_write_close equivalent), the session > won't be able to log the data and there would be no warning to the > client as engine is in auto tidy up mode. >
Hi, Many thanks for your question, because I hadn't given the matter much thought. The current patch (#7) uses static methods so it doesn't change the status quo - the user would need still need to manually close the session (or register a shutdown function) in order to use an object in the close() method. I've spent some time thinking about this and I think we have a couple of options. First of all I've changed the interface so that the methods are no longer static, it would already accept an object before but it would just use it find the class name, and call the methods statically. Now it only accepts an object. The two options I've implemented are: Destructor in the SessionHandler class: http://spellign.com/patches/php-trunk-session-oo8-destruct.patch This works ok with some provisions: - The user's SessionHandler class must hold on to any objects it will need in close(), (in a property, presumably). While it's possible that the session handler would still get destructed afterwards, this is the only way to ensure it. - If the user overrides __destruct(), they must call parent::__destruct(). Automatically register a shutdown function: http://spellign.com/patches/php-trunk-session-oo8-shutdown_function.patch The only argument I can think of against it is that it's possible the user might, out of habit, register their own shutdown function *after* calling session_set_save_handler(). In that case their shutdown function would find the session already closed. > Obviously, if the developer takes care and calls the destructors in > the right order, then everything will be OK, but this is not something > I see very often. > > What about circular references and interdependent references? > This would give the destructor option some trouble - in this case instances are destructed in the order in which they were created, and it seems likely that the DB object from your example would be created first. I prefer the shutdown function option. We could even ensure that the user's shutdown function always gets called first by adding a separate hash of internal shutdown functions, however I think that would overcomplicate matters for something we can clearly document. The option I haven't mentioned is to preserve the status quo, I think that would be a pity since we have the chance to address it while keeping BC now. I've moved the tests into a separate patch so the above differences are clearer: http://spellign.com/patches/php-trunk-session-oo8-tests.patch Regards, Arpad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
