Cleanup: sessions

[Co...@eng.sun.com]

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);

    public void accessed(HttpSession session);
}

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

Re: Cleanup: sessions

["Craig R. McClanahan" <cm...@mytownnet.com>]

Costin.Manolache@eng.sun.com wrote:

> > 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).
>
> Well, there is a reason to pass both - the method might affect the response,
> and it is important to have this clear in the signature instead of having a
> side effect.
> Also, both Request and Response are available - I see no reason to add an
> extra request.getResponse() ( that will be needed since response is allways
> used to create a new session)
>

That's a good enough reason for me.

>
> > >
> > >     public void accessed(HttpSession session);
> >
> > This updates the "last accessed time" value, right?
>
> Yes.
>
> Also note that a SessionManager needs to use the public methods in
> Request/Response.
>
> If you need more - you can make more methods public, but with a lot of care
> as this will affect the interfaces we'll put on Request/Response.
>

I will take a look tonight ... we can walk that tightrope an inch at a time.

>
> Costin
>

Craig

Re: Cleanup: sessions

[Co...@eng.sun.com]

> 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).

Well, there is a reason to pass both - the method might affect the response,
and it is important to have this clear in the signature instead of having a
side effect.
Also, both Request and Response are available - I see no reason to add an
extra request.getResponse() ( that will be needed since response is allways
used to create a new session)

> >
> >     public void accessed(HttpSession session);
>
> This updates the "last accessed time" value, right?

Yes.


Also note that a SessionManager needs to use the public methods in
Request/Response.

If you need more - you can make more methods public, but with a lot of care
as this will affect the interfaces we'll put on Request/Response.

Costin

Re: Cleanup: sessions

["Craig R. McClanahan" <cm...@mytownnet.com>]

+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

Re: Cleanup: sessions

[Assaf Arkin <ar...@exoffice.com>]

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

Beautiful.

> 
> - 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() ).

Makes a lot of sense. (I have an itch for doing session persistence :-)
)

arkin


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