[Seaside-dev] collecting expired stuff

[Julian Fitzell]

Actually, I sort of agree with you. The request context should
indicate the dispatch chain of request handlers but a Session is very
closely tied to an Application (I have said before that
ApplicationInvocation or something would really be a more accurate
name than Session) and it does kind of make sense that it should know
what Application it is an "invocation" of.

It would be convenient to be able to call #unregister on a Session
that is not the "current" session as far as the RequestContext is
concerned.

The expiry is always triggered from within the Application though (and
doesn't use #unregister), so that should not be the cause of your
lingering sessions.

Julian

On Tue, Mar 10, 2009 at 10:15 PM, Sebastian Sastre <ssastre at seaswork.com> wrote:
> hi there,
> my dev image reached 100MB somehow so I'm making some instance cleaning.
> I can see a request not found when sending #unregister to non collected
> sessions.
> I don't know yet why those sessions where not collected and is an issue of mine
> for sure but I can't say the expiring technique of 2.9 is helping nor bullet
> proof.
> Are that dependence really needed? I mean, to need a request context for
> reaching the application of a session?
>
> sebastian
>
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>