* Benjamin Slavin ([EMAIL PROTECTED]) wrote:
> The get_new_session_key method would probably be a good place to
> start, though I have little familiarity with the interface to the
> session middleware.  I'm swamped right now, so I'll look into it in
> the next few days.  If you need any assistance, please let me know.

I'll try to play around with it some more, if even just for the learning
experience.

> > * An auto purge algorithm that clears expired sessions
> 
> +1 on the idea / +0 on the implementation
> 
> I've never liked the idea of randomly slowing down requests to perform
> housekeeping tasks.  It's probably acceptable in low-volume sites, but
> for high-traffic sites with a cluster of web servers a dedicated
> process more sense to me.
> 
> I think auto purge would need further discussion to figure out the
> best solution.

To go with the 80/20 rule, I'd imagine that for 80% of Django developers
something like this would work pretty well and be useful.  If you can
disable it for those other cases where you do have a cluster of web
servers, would that be good enough?  Plus, aren't we talking about a
10th of a second or less to purge the table?  It is a good point that if
you have 5 web servers fronting a single database backend and each has
their own probabilities of running session GC, that's not optimal.

Is there a way to make this happen *after* all the content was sent to
the user and the HTML tag closed?

-Rob

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to