tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <cmcclana...@mytownnet.com>
Subject Re: Cleanup: sessions
Date Fri, 07 Jan 2000 20:29:18 GMT
+1, but with a couple of nit-pick questions embedded below.

For those who came in recently and don't know what "Tomcat.Next" is, the
proposal is at a temporary URL:

    http://www2.mytownnet.com/tomcat

at the moment, because it was too unwieldy to deal with as email.  Tonight
(when I get home), I'm going to be checking this in to a directory in the
jakarta-tomcat CVS tree, but separate from the source code, to make it
easily visible.

Craig


Costin.Manolache@eng.sun.com wrote:

> Hi,
>
> In order to "modularize" the session management, we need to
> do some changes.
> Please let me know what you think, and if anyone has a -1 I'll
> rollback.
>
> -  Move all session related stuff out of core ( in tomcat.session ).
> This will reduce the number of classes in core and will allow us
> to define a clear interface between session stuff and core.
>
> It seems the minimal interface that will keep everythin working is:
>
> interface SessionManager {
>
>     public HttpSession getSession(Request request, Response
> response,boolean create);
>

Is it necessary to pass the response here in order to create the session?  I
was under the impression that the Request itself already knew which Response
it was associated with, and you could therefore follow the chain if you
really needed to (for setting the cookie, for example).

>
>     public void accessed(HttpSession session);

This updates the "last accessed time" value, right?

>
> }
>
> In order to define a new session management you need to implement this
> interface.
>
> - Change. Instead of singleton, a SessionManager will be set for each
> context.
> It's up to the configuration code ( which will be done later) to tune
> each
> manager ( the default is the current code until something else is stable
> ).
>
> - The SessionManager is _required_ to respect the APIs. Any parameter
> that
> is defined by the deployment descriptor will be specified and set up in
> Context.
> SessionManager tuning can be done for things like database persistence,
> etc.
>
> - SessionInterceptor ( the default == the current code ) will call the
> session
> manager of the current context ( and it will be called after the context
>
> is determined ). Feel free to use a different Interceptor if you don't
> like
> this model. ( for example Apache may send the session id, and your
> interceptor may use a different internal API to mark it as accessed ).
> A session interceptor is _required_ in order to mark as accessed the
> session ( user doens't have to call getSession() ).
>
> - Internally, tomcat.core will use HttpSession. Your manager can
> cast to it's internal implementation ( and it's guaranteed that accessed
>
> will receive the object generated by getSession()).
>
> Let me know what you think, I'll check in later today or tommorow.
> ( also - read Craig's Tomcat.Next - he's much better at explaining!)
>
> Costin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message