On Mon, Jun 20, 2011 at 10:37 AM, Richard Quadling <rquadl...@gmail.com> wrote: > On 20 June 2011 01:39, Arpad Ray <array...@gmail.com> wrote: >> 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 >> > > Thanks for looking into this a lot more. > > I've always used a First-In-Last-Out (FILO) creation/destruction order > and incorporated the concept of "ownership". > > Any time an instance of a class is created, it has to be "owned" by > another instance (of any type) or by a pseudo top-parent. In my case, > I always have an instance of tApp, to which I attach my DB resource > container (invariable I communicate with multiple unlink DB servers) > and a session class (old skool). > > tApp is created, DB(s) are linked to. Session is started. > > As part of the app destructor, the session is closed first. Always. > Then the DB connectors. For me, during the shutdown of tApp, there is > no more activity to be processed, so the cleanup can take place in a > controlled manner. And the reverse order seems the best way. > > And I always call the destructor on tApp as part of my code. A > try{}finally{} clause would certainly be beneficial but probably not > essential. > > Hopefully, by the time my script has finished, all resources are > closed and finalised and the script engine shutdown/cleanup cycle is > doing nothing. > > > Essentially, it is moving the cleanup process into the hands of the > developer. If they don't control the order, I'm not sure you can > predict the order. Or if it can be predicted, it may not be the > desired order. > > > > I think this is a great addition to PHP. I think it needs to be > PHP\SessionHandler. I think all new classes should be namespaced to > PHP, but that's another topic I'm sure. > > > -- > Richard Quadling > Twitter : EE : Zend : PHPDoc > @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea >
Hi, I've updated the patches with some changes suggested by Derick: * Added PHPAPI in a couple of places so it doesn't break on Windows * Changed PSF to PHP_SESSION_FUNC to avoid possible conflicts * Split the tests into separate files I'm also only including the shutdown function option, since I think the destructor option is so clearly inferior for the reasons outlined in my previous email that it's not worth complicating the vote. The new patches are at: http://spellign.com/patches/php-trunk-session-oo9.patch http://spellign.com/patches/php-trunk-session-oo9-tests.patch Regards, Arpad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
