On Feb 14, 2008, at 2:01 AM, titetluc titetluc wrote:
There were multiple suggestions that worked through the sort of
callback solution you describe: mod_auth_tkt, CHI, storing a timestamp
in the session (as opposed to in a separate column in the sessions
database table), Apache::SessionManager...
All of these modules propose an expiration mechanism, but they do
not propose a mechanism to automatically destroy session at
expiration (this is what I call a "callback" mechanism).
This implies that the session destruction has to be called explicitly.
We could imagine an interface where a callback is defined when a
session is created
For example,
session_create(inactivity => 30, callback => sub{print "Session
automagically destroyed";})
There would be no need to call a session_delete function !!
when you're creating a callback function like that, you're specifying
the expiration... which means you're requiring some sort of polling
service to continually check the timing ( OLL, not OOL )
none of the perl modules do this, because something of that sort is
application or framework specific -- and will depend heavily on your
session datastore setup and parameters.
there might be something like that built into a framework like
catalyst... but callback functions and stuff like that are more of a
'framework' style feature, and not a module feature -- as they
require a bit of customization AND some sort of polling mechanism.
your inactivity notion requires some mechanism to constantly poll the
session store every second, looking for items newly ready for
deletion. frameworks that offer that, for example Twisted Python,
use a 'reactor' style daemon that has a subprocess that polls the db
for expiration time. however -- no systems i've seen expires
automatically, they all batch delete items that are past-expiration
at regular intervals. the intervals are either realized through an
internal timer on the daemon, or they use a hook every request to see
if it is time yet to empty the cache. This is considered a feature -
you dont want to waste CPU on deleting sessions every second.
if you were to take the combined advice of people on this list, you
could have a trivial solution that meets your goals.
i. create a session_create function, instantiate sessions with it.
have it specify a 'session inactivity' time and last acessed time.
a. db store
table: session
cols: session_id , inactivity , last_accessed ,
data
b. kv ( memcached ) store
table: session
cols: session_id , data
table: session_activity
cols session_id , timestamp_active +
session->data->inactivity time
ii. overload the session access/saving mechanism to update the
last_accessed time
iii. create a polling standalone script, or some internal method
that expires the 'deletion ready' sessions at intervals, using some
sort of hook
the exact system that you described however is impossible under
mod_perl , which is request based ( a perl interpreter embedded under
apache).
you could do it with an event driven framework like poe ( http://
poe.perl.org ) or perlbal ( http://www.danga.com/perlbal/ ) , which
daemonize and will allow you to make time-based polling processes.
you could also use mod_perl for the request processing, and write a
session expiry system in an event driven framework ( or even use cron/
at jobs to trigger shell scripts )
// Jonathan Vanasco
w. http://findmeon.com/user/jvanasco
e. [EMAIL PROTECTED]
| Founder/CEO - FindMeOn, Inc.
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Privacy Minded Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
