2008/2/13, Perrin Harkins <perrin@elem.com>:
On Feb 13, 2008 2:03 AM, titetluc titetluc <titetluc@gmail.com> wrote:
> By pooling, I mean the fact that expired sessionS have to be REGULARLY purge
> (in opposed to a callback mechanism (IMHO,  the best solution ). This
> callback would be called on ONE session expiration and would suppress it.
> You would not have any purge latency with such a solution).

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 !!


- Perrin