[Tomcat 4] Session Handling Enhancements

["Craig R. McClanahan" <Cr...@eng.sun.com>]

The session handling enhancements proposed by Kief Morris
<ji...@bitbull.com> have been committed on the Tomcat 4.0 CVS
repository.  On an initial review, I plan to make the following changes,
and welcome additional thoughts and comments:

(1) Session Save/Restore Across App Restarts

Currently, StandardManager saves and restores sessions across app
restarts (i.e. autoreload if turned on, or normal shutdown and
startup).  It should be modified to use the new passivate() and
activate() methods of the session implementation to warn interested
session attributes that this activity is taking place.

(2) Modify StandardSession.readObject() and writeObject()

Currently, when the session is being serialized, the attributes are
removed via removeAttribute() -- which triggers calls to valueUnbound()
of attributes that implement HttpSessionBindingListener, among other
things.  Likewise, when the session is reloaded in readObject,
setAttribute() is called and triggers calls to valueBound().  These
calls were initially made to give session attributes some knowledge that
a restart was being done.

Now that the activate and passivate mechanisms are in place, I propose
that these mechanisms be changed to *not* unbind and bind the attributes
during these processes.  Any interested attribute can implement
HttpSessionAttributeListener instead.

(3) Change "final" classes

One of the challenges Kief ran into is that StandardManager and
StandardSession are both marked final, and therefore cannot be
subclassed.  I propose to remove the "final" modifier so that this
restriction is no longer in place.  Additional refactoring can be
performed separately, but you should at least be able to subclass these
classes.

Craig

Re: [Tomcat 4] Session Handling Enhancements

[Pier Fumagalli <pi...@betaversion.org>]

Craig R. McClanahan <Cr...@eng.sun.com> wrote:
> 
> The session handling enhancements proposed by Kief Morris
> <ji...@bitbull.com> have been committed on the Tomcat 4.0 CVS
> repository.

Way cool... Thanks Kief...

-- 
Pier Fumagalli                                 <ma...@betaversion.org>

Re: [Tomcat 4] Session Handling Enhancements

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Kief Morris wrote:

> Craig R. McClanahan typed the following on 04:40 PM 2/5/2001 -0800
> >(1) Session Save/Restore Across App Restarts
> >
> >Currently, StandardManager saves and restores sessions across app
> >restarts (i.e. autoreload if turned on, or normal shutdown and
> >startup).  It should be modified to use the new passivate() and
> >activate() methods of the session implementation to warn interested
> >session attributes that this activity is taking place.
>
> -0 How about stripping this entirely out of StandardManager? People who
> want to keep sessions over restarts can use PersistentManager, leaving
> StandardManager as a slimmer, simpler default.
>

Well, StandardManager already supports saving and restoring sessions across
restarts -- it just doesn't do the event notifications right.

>
> (2) Modify StandardSession.readObject() and writeObject()
> >
> >Currently, when the session is being serialized, the attributes are
> >removed via removeAttribute() -- which triggers calls to valueUnbound()
> >of attributes that implement HttpSessionBindingListener, among other
> >things.  Likewise, when the session is reloaded in readObject,
> >setAttribute() is called and triggers calls to valueBound().  These
> >calls were initially made to give session attributes some knowledge that
> >a restart was being done.
> >
> >Now that the activate and passivate mechanisms are in place, I propose
> >that these mechanisms be changed to *not* unbind and bind the attributes
> >during these processes.  Any interested attribute can implement
> >HttpSessionAttributeListener instead.
>
> You mean HttpSessionActivationListener? If so I'm +1 on this - I can make
> this change.
>
> >(3) Change "final" classes
> >
> >One of the challenges Kief ran into is that StandardManager and
> >StandardSession are both marked final, and therefore cannot be
> >subclassed.  I propose to remove the "final" modifier so that this
> >restriction is no longer in place.  Additional refactoring can be
> >performed separately, but you should at least be able to subclass these
> >classes.
>
> +1 - I can do this also.
>

I've actually got a commit ready to go on all of these, plus an extended unit
test to prove that it fires all the right events at the right time.  I'll go
ahead and check it in.

>
> What do you think about pushing more functionality up into ManagerBase,

Either that, or subclass StandardManager instead if it makes life easier.

>
> and creating a SessionBase class?

Sounds good as well.

> Most of what I want to do shouldn't
> need subclassing of StandardManager/Session.
>

Some of the places where we're casting to StandardSession seem to imply that
these methods should really be in the Session interface itself.  I was
particularly thinking about the new activate() and passivate() methods, which
every session implementation should be ready to implement.  There are
probably others as well.

>
> Kief
>

Craig

Re: [Tomcat 4] Session Handling Enhancements

[Kief Morris <ki...@bitbull.com>]

Craig R. McClanahan typed the following on 04:40 PM 2/5/2001 -0800
>(1) Session Save/Restore Across App Restarts
>
>Currently, StandardManager saves and restores sessions across app
>restarts (i.e. autoreload if turned on, or normal shutdown and
>startup).  It should be modified to use the new passivate() and
>activate() methods of the session implementation to warn interested
>session attributes that this activity is taking place.

-0 How about stripping this entirely out of StandardManager? People who
want to keep sessions over restarts can use PersistentManager, leaving
StandardManager as a slimmer, simpler default.

(2) Modify StandardSession.readObject() and writeObject()
>
>Currently, when the session is being serialized, the attributes are
>removed via removeAttribute() -- which triggers calls to valueUnbound()
>of attributes that implement HttpSessionBindingListener, among other
>things.  Likewise, when the session is reloaded in readObject,
>setAttribute() is called and triggers calls to valueBound().  These
>calls were initially made to give session attributes some knowledge that
>a restart was being done.
>
>Now that the activate and passivate mechanisms are in place, I propose
>that these mechanisms be changed to *not* unbind and bind the attributes
>during these processes.  Any interested attribute can implement
>HttpSessionAttributeListener instead.

You mean HttpSessionActivationListener? If so I'm +1 on this - I can make
this change.

>(3) Change "final" classes
>
>One of the challenges Kief ran into is that StandardManager and
>StandardSession are both marked final, and therefore cannot be
>subclassed.  I propose to remove the "final" modifier so that this
>restriction is no longer in place.  Additional refactoring can be
>performed separately, but you should at least be able to subclass these
>classes.

+1 - I can do this also. 

What do you think about pushing more functionality up into ManagerBase,
and creating a SessionBase class? Most of what I want to do shouldn't
need subclassing of StandardManager/Session.

Kief