Zend_Session -- extend, or not, to clean-up fore than "just" session data ?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Zend_Session -- extend, or not, to clean-up fore than "just" session data ?

OpenMacNews-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

hi all,

now that my site is Zend_Config'd, i've started looking at the
Zend_Session proposal in a bit more earnest.

reading through the proposal & source, and php docs on native
session/gc, i've got a handle on its use for "just" session data.

i'm interested in "hooking" into it ... kinda fuzzy, so let me try a
scenario/example ...

revisiting an earlier question, i'm thinking -- again -- about its use
in gc'ing tangible resources that are relevant only to & during a given
session.

e.g., dymanic images created for a user's particular session.

since they are to be displayed in browser, they're saved to:

        (document root)/images/tmp/

in subdirectories that i'm naming by session_id(). e.g., images are
created as:

        (document root)/images/tmp/1Y,0-bhUbmiilS,6kmZTX6p10x8/image.png


when i *cleanly* leave the site, a cleanup routine in the ZF
Controller's __destructor rm's the current session_id's associated
images subdirectory.

all good.

BUT, if the site is left UNcleanly, e.g., via forced browser close,
although the session dies, and the session data will eventually get GC'd
per the php.ini session.gc_* specs, those session_id-named subdirs never
get removed by that destructor, as the session is no longer the
current/same id.


sooooo, i *could* add a cleanup routine to the Controller -- either
destructor or constructor would do, i think -- , determine a list of
active session IDs @ the server level, scan/parse the image/tmp dir, and
delete dirs unmatched against an active session.

apart from the fact that that feels 'clunky' to me, i immediately wonder
if i can't leverage Zend_Session's access to session ids, session data &
gc routines, and extend to add this "real file" management.


QUESTION: is Zend_Session-to-be the right place to be dealing with this?

there's gotta (should?) be a smarter/more convenient way to manage
transient files ...

interested in your thoughts ...

cheers,

richard
- --

/"\
\ /  ASCII Ribbon Campaign
 X   against HTML email, vCards
/ \  & micro$oft attachments

[GPG] OpenMacNews at gmail dot com
fingerprint: 50C9 1C46 2F8F DE42 2EDB  D460 95F7 DDBD 3671 08C6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iEYEAREDAAYFAkRv3dcACgkQlffdvTZxCMZK+gCcDKtEBMBP0l/ZXMXYBrTRtmsz
L8IAn3xn0WKqlF07ScrLYD3UAOSTUsoW
=Qj2Q
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Zend_Session -- extend, or not, to clean-up fore than "just" session data ?

Jayson Minard (ZF)
Richard,

I'm marking this one to look at when I'm into Zend_Session in a few days...
It feels out of scope from my first impression, but worth double checking
anyway.

--j


On 5/20/06 8:26 PM, "Richard" <[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
> hi all,
>
> now that my site is Zend_Config'd, i've started looking at the
> Zend_Session proposal in a bit more earnest.
>
> reading through the proposal & source, and php docs on native
> session/gc, i've got a handle on its use for "just" session data.
>
> i'm interested in "hooking" into it ... kinda fuzzy, so let me try a
> scenario/example ...
>
> revisiting an earlier question, i'm thinking -- again -- about its use
> in gc'ing tangible resources that are relevant only to & during a given
> session.
>
> e.g., dymanic images created for a user's particular session.
>
> since they are to be displayed in browser, they're saved to:
>
> (document root)/images/tmp/
>
> in subdirectories that i'm naming by session_id(). e.g., images are
> created as:
>
> (document root)/images/tmp/1Y,0-bhUbmiilS,6kmZTX6p10x8/image.png
>
>
> when i *cleanly* leave the site, a cleanup routine in the ZF
> Controller's __destructor rm's the current session_id's associated
> images subdirectory.
>
> all good.
>
> BUT, if the site is left UNcleanly, e.g., via forced browser close,
> although the session dies, and the session data will eventually get GC'd
> per the php.ini session.gc_* specs, those session_id-named subdirs never
> get removed by that destructor, as the session is no longer the
> current/same id.
>
>
> sooooo, i *could* add a cleanup routine to the Controller -- either
> destructor or constructor would do, i think -- , determine a list of
> active session IDs @ the server level, scan/parse the image/tmp dir, and
> delete dirs unmatched against an active session.
>
> apart from the fact that that feels 'clunky' to me, i immediately wonder
> if i can't leverage Zend_Session's access to session ids, session data &
> gc routines, and extend to add this "real file" management.
>
>
> QUESTION: is Zend_Session-to-be the right place to be dealing with this?
>
> there's gotta (should?) be a smarter/more convenient way to manage
> transient files ...
>
> interested in your thoughts ...
>
> cheers,
>
> richard
> - --
>
> /"\
> \ /  ASCII Ribbon Campaign
>  X   against HTML email, vCards
> / \  & micro$oft attachments
>
> [GPG] OpenMacNews at gmail dot com
> fingerprint: 50C9 1C46 2F8F DE42 2EDB  D460 95F7 DDBD 3671 08C6
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (Darwin)
>
> iEYEAREDAAYFAkRv3dcACgkQlffdvTZxCMZK+gCcDKtEBMBP0l/ZXMXYBrTRtmsz
> L8IAn3xn0WKqlF07ScrLYD3UAOSTUsoW
> =Qj2Q
> -----END PGP SIGNATURE-----
>


Reply | Threaded
Open this post in threaded view
|

Re: Zend_Session -- extend, or not, to clean-up fore than "just" session data ?

OpenMacNews-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

hi jayson,

Jayson Minard wrote, On 5/22/06 10:07 AM:
> I'm marking this one to look at when I'm into Zend_Session in a few days...
> It feels out of scope from my first impression, but worth double checking
> anyway.

entirely possible abt the scope ... i'm "waffling" myself :-/

thanks for keeping this in mind.

cheers,

richard

- --

/"\
\ /  ASCII Ribbon Campaign
 X   against HTML email, vCards
/ \  & micro$oft attachments

[GPG] OpenMacNews at gmail dot com
fingerprint: 50C9 1C46 2F8F DE42 2EDB  D460 95F7 DDBD 3671 08C6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iEYEAREDAAYFAkRx8u0ACgkQlffdvTZxCMYcqgCdGZJMFlyHfWXXks8ukbdV6Lqg
kEsAn17bJY8HjkeiiwaG39MD9mp31Yxl
=0QTh
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Zend_Session -- extend, or not, to clean-up fore than "just" session data ?

Ralph Schindler
Richard wrote:

>> I'm marking this one to look at when I'm into Zend_Session in a few days...

Awesome, I am looking forward to comments from Zend on this :)


>>
>> reading through the proposal & source, and php docs on native
>> session/gc, i've got a handle on its use for "just" session data.
>>
>> i'm interested in "hooking" into it ... kinda fuzzy, so let me try a
>> scenario/example ...

Considering Zend has not looked at the proposed api in proposal v3 yet,
I hesitate on releasing my new version of Zend_Session that has the
plugin interface implemented (sort-of).  The idea behind the data
plugins is that, once a new plugin is registered, it will have a
namespace in _SESSION it can manage via: set, get, has and remove
functionality.  It will also be able to register custom startup() and
destroy() functions.  Much like Zend_Front_Controller's plugin architecture

>> revisiting an earlier question, i'm thinking -- again -- about its use
>> in gc'ing tangible resources that are relevant only to & during a given
>> session.
>>
>> e.g., dymanic images created for a user's particular session.

Personally, I would that since the domain logic of creating these images
exists in some class, that class should also manage the
destruction/cleanup of the things it creates..  I agree that there
should be some static methods, perhaps in the Zend_Session_Tools class,
that will do things like Zend_SEssion_Tools::sessionStillExists() or
Zend_Session_Tools::getAllSessionIds().. But that is not functionality
that exists in the ext/session extension since ext/session is session
centric and not sessions centric, if that makes sense.


>> sooooo, i *could* add a cleanup routine to the Controller -- either
>> destructor or constructor would do, i think -- , determine a list of
>> active session IDs @ the server level, scan/parse the image/tmp dir, and
>> delete dirs unmatched against an active session.
>>
>> apart from the fact that that feels 'clunky' to me, i immediately wonder
>> if i can't leverage Zend_Session's access to session ids, session data &
>> gc routines, and extend to add this "real file" management.

Your controller might be the place to implement garbage collection.  In
a similar style to session_gc functionality:

         // garbage collection - similar to php's gc
         if ($this->_gc_probability > 0)
         {
             if (mt_rand(0, $this->_gc_divisor) < $this->_gc_probability)
                 $this->_garbageCollection();
         }


divisor 1 and probability 100

means a 1% chance of running.

then in the gc function, just check to see if the files are older than
the same amount of time as your session, perhaps 2 weeks?

>>
>> QUESTION: is Zend_Session-to-be the right place to be dealing with this?
>>
>> there's gotta (should?) be a smarter/more convenient way to manage
>> transient files ...

jury still out on this one, technically, the api for Zend_Session needs
to be nailed down first, then one can answer this question correctly ;)


-ralph

Reply | Threaded
Open this post in threaded view
|

Re: Zend_Session -- extend, or not, to clean-up fore than "just" session data ?

OpenMacNews-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

hi ralph,

>>> I'm marking this one to look at when I'm into Zend_Session in a few
>>> days...
>
> Awesome, I am looking forward to comments from Zend on this :)

hey, look, it's a party! :-)

>>> i'm interested in "hooking" into it ... kinda fuzzy, so let me try a
>>> scenario/example ...
>
> Considering Zend has not looked at the proposed api in proposal v3 yet,
> I hesitate on releasing my new version of Zend_Session that has the
> plugin interface implemented (sort-of).  The idea behind the data
> plugins is that, once a new plugin is registered, it will have a
> namespace in _SESSION it can manage via: set, get, has and remove
> functionality.  It will also be able to register custom startup() and
> destroy() functions.  Much like Zend_Front_Controller's plugin architecture

just a thought, but since Jayson will be getting to thinking abt this in
a bit, you may want to get that version in front of him for
thought-starter / consideration ...

>>> revisiting an earlier question, i'm thinking -- again -- about its use
>>> in gc'ing tangible resources that are relevant only to & during a given
>>> session.
>>>
>>> e.g., dymanic images created for a user's particular session.
>
> Personally, I would that since the domain logic of creating these images
> exists in some class, that class should also manage the
> destruction/cleanup of the things it creates..  I agree that there
> should be some static methods, perhaps in the Zend_Session_Tools class,
> that will do things like Zend_SEssion_Tools::sessionStillExists() or
> Zend_Session_Tools::getAllSessionIds().

yup. we're on the same page ...

> But that is not functionality
> that exists in the ext/session extension since ext/session is session
> centric and not sessions centric, if that makes sense.

enuf for now :-)

>>> sooooo, i *could* add a cleanup routine to the Controller -- either
>>> destructor or constructor would do, i think -- , determine a list of
>>> active session IDs @ the server level, scan/parse the image/tmp dir, and
>>> delete dirs unmatched against an active session.
>>>
>>> apart from the fact that that feels 'clunky' to me, i immediately wonder
>>> if i can't leverage Zend_Session's access to session ids, session data &
>>> gc routines, and extend to add this "real file" management.
>
> Your controller might be the place to implement garbage collection.  In
> a similar style to session_gc functionality:
>
>         // garbage collection - similar to php's gc
>         if ($this->_gc_probability > 0)
>         {
>             if (mt_rand(0, $this->_gc_divisor) < $this->_gc_probability)
>                 $this->_garbageCollection();
>         }
>
>
> divisor 1 and probability 100
>
> means a 1% chance of running.
>
> then in the gc function, just check to see if the files are older than
> the same amount of time as your session, perhaps 2 weeks?

that's a clever idea.  hadn't thought yet abt doing the date/time
comparison ...

>>> QUESTION: is Zend_Session-to-be the right place to be dealing with this?
>>>
>>> there's gotta (should?) be a smarter/more convenient way to manage
>>> transient files ...
>
> jury still out on this one, technically, the api for Zend_Session needs
> to be nailed down first, then one can answer this question correctly ;)

fair nuf.  i'll stay tuned-in!

thx again,

richard

- --

/"\
\ /  ASCII Ribbon Campaign
 X   against HTML email, vCards
/ \  & micro$oft attachments

[GPG] OpenMacNews at gmail dot com
fingerprint: 50C9 1C46 2F8F DE42 2EDB  D460 95F7 DDBD 3671 08C6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iEYEAREDAAYFAkRyDoUACgkQlffdvTZxCMatywCdEfqo+k8g33Ia89kPQv9rAOGD
bgwAn2L7BhWMSSHR20jyswNoRyzxVGJy
=Qqsu
-----END PGP SIGNATURE-----