sessions again

[jon * <jo...@latchkey.com>]

Ok,

I'm going through and implementing this session reload stuff in Tomcat (not
Catalina yet since I'm currently using Tomcat). Anyway, here is a problem
that I'm running into:

Currently, the SessionManager interface does not have any way to get a list
of all the sessions. The StandardManager does have this ability
(findSessions()), but since this isn't part of SessionManager, so I can't
reliably use that interface in my code, I have to code specifically for the
StandardManager which would be bad.

So, my question is this: can I add the findSessions() method to the
SessionManager interface?

Second question (which kind of nullifies the first because I won't really be
externally using the findSessions() method if this is ok):

Can I also add a method to both SessionManager and StandardManager that will
return a Hashtable instead of a HttpSession[]? The reason is that it will be
easier to do the serialization. I will need to create this Hashtable anyway
from the HttpSession[] so it would be nice to just have this method in a
re-usable location instead.

thanks,

-jon




-- 
    Java Servlet Based - Open Source  |        Collab.Net
        Bug/Issue Tracking System     |   now hiring smart people
       <http://scarab.tigris.org/>    |  <http://Collab.Net/jobs/>

Re: sessions again

[Costin Manolache <co...@costin.dnt.ro>]

Hi Jon,

Sorry for answering so late.

> hmmm...you are right, I guess I could have done that. My excuse is #1. my
> lack of understanding of tomcat and #2. the fact that costin put it into my
> head that this functionality should be in a separate class...i guess i just
> fixated on not tying this class to anything else...

> one problem with doing that though is that StandardSession is tied to
> StandardManager when it probably should have been tied to SessionManager
> instead.

All I said is that the session management stuff shouldn't depend on tomcat
internals - i.e. how the request is represented, internal tomcat objects, etc.

SessionManager is the result of extracting the minimal set of contracts
required by tomcat - that's all you need to implement to make something
work with tomcat. If you need something more - please feel free to add
it. If you don't need - please don't add :-)

In fact it should be easy to create an adapter for the code in Catalina -
except that it's not easy to share code between the 2 projects.

This sucks - I can't understand why some people don't want to share code, but
that's another problem. If you can convince Craig to remove the dependencies
from Manager to Container ( get/setContainer)  it may be possible to just
use the same implementation.

( The current session management code in tomcat is in fact derived from a
previous version of Catalina.  )

Costin

Re: sessions again

[jon * <jo...@latchkey.com>]

on 5/15/2000 2:31 PM, Craig R. McClanahan <Cr...@eng.sun.com>
wrote:

> Betcha the deserializer of a Hashtable does pretty much the same loop :-).

probably...but it just seemed cleaner to me...I would rather hide looping
code in lower classes than expose it higher up...

> OK, I see.  I would have expected the stuff you put in SessionSerializer to go
> into
> a subclass of StandardManager (if you didn't want to have support of this in
> the
> default session manager), which would have had direct access to the hashtable
> anyway.

hmmm...you are right, I guess I could have done that. My excuse is #1. my
lack of understanding of tomcat and #2. the fact that costin put it into my
head that this functionality should be in a separate class...i guess i just
fixated on not tying this class to anything else...

one problem with doing that though is that StandardSession is tied to
StandardManager when it probably should have been tied to SessionManager
instead.

> At any rate, it's a configurable feature of the default session manager in
> Catalina.

cool...that is all that we care about. :-)

> PS:  Thanks for pointing out one more thing I have to fix (deserializer has to
> use the right class loader)!

yep...that is a key point not to miss... :-)

also...i'm not sure if it is possible to add a watchdog test for this or not
(i have no experience with it), but essentially it would go something like
this:

use the SessionExample.java class to create a new session. touch that class
to change the mod date. the session id should still be the same on the next
request and contain the same data.

-jon

-- 
    Java Servlet Based - Open Source  |        Collab.Net
        Bug/Issue Tracking System     |   now hiring smart people
       <http://scarab.tigris.org/>    |  <http://Collab.Net/jobs/>

Re: sessions again

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

jon * wrote:

> on 5/15/2000 12:59 PM, Craig R. McClanahan <Cr...@eng.sun.com>
> wrote:
>
> > But, in general, why do you need to get back a Hashtable?  Just so you can
> > serialize the whole thing in one fell swoop?  In Catalina, I do the
> > serialization like this:
> >
> > Session sessions[] = manager.findSessions();
> > Serialize the number of sessions as an integer
> > Loop through the array, serializing each session
> > individually (after dealing with the non-serializable
> > attributes, of course).
> >
> > and deserialization reads the counter first so it knows how many sessions to
> > load.  This way, you don't expose internal data structures of the Manager
> > anywhere.
>
> Yea, Costin asked that I implement this as a single class...so, not only did
> I do that, but I made it all static (hehehe)...thus, it is a one line
> addition to ServletWrapper.handleReload()...I will be checking it in
> soon...you can see what/why I did...although, it is slightly nasty in that i
> simply replace the SessionManager hashtable directly...
>
> Essentially, yes, I just wanted to do something like this:
>
>     o.writeObject(sessionHashtable);

>
> The code is simpler and avoids having to do an extra loop (this reloading
> stuff is slow enough as it is)...
>

Betcha the deserializer of a Hashtable does pretty much the same loop :-).

>
> I just finished my testing...I will commit the code and you can check it
> out...
>

OK, I see.  I would have expected the stuff you put in SessionSerializer to go into
a subclass of StandardManager (if you didn't want to have support of this in the
default session manager), which would have had direct access to the hashtable
anyway.

At any rate, it's a configurable feature of the default session manager in Catalina.

>
> -jon
>

PS:  Thanks for pointing out one more thing I have to fix (deserializer has to use
the right class loader)!

Re: sessions again

[jon * <jo...@latchkey.com>]

on 5/15/2000 12:59 PM, Craig R. McClanahan <Cr...@eng.sun.com>
wrote:

> You won't need to worry about it for Catalina, because it's already there (I'm
> going to add the change you just made about unbinding any non-serializable
> attributes so they don't just disappear).

Awesome! One more thing that I had to add in readObject() was the
re-creation of the hashtable for some reason...it was NPE after the reload.

> I don't really care what you add to the Tomcat 3.1 classes.

:-)
 
> But, in general, why do you need to get back a Hashtable?  Just so you can
> serialize the whole thing in one fell swoop?  In Catalina, I do the
> serialization like this:
> 
> Session sessions[] = manager.findSessions();
> Serialize the number of sessions as an integer
> Loop through the array, serializing each session
> individually (after dealing with the non-serializable
> attributes, of course).
> 
> and deserialization reads the counter first so it knows how many sessions to
> load.  This way, you don't expose internal data structures of the Manager
> anywhere.

Yea, Costin asked that I implement this as a single class...so, not only did
I do that, but I made it all static (hehehe)...thus, it is a one line
addition to ServletWrapper.handleReload()...I will be checking it in
soon...you can see what/why I did...although, it is slightly nasty in that i
simply replace the SessionManager hashtable directly...

Essentially, yes, I just wanted to do something like this:

    o.writeObject(sessionHashtable);

The code is simpler and avoids having to do an extra loop (this reloading
stuff is slow enough as it is)...

I just finished my testing...I will commit the code and you can check it
out...

-jon

-- 
    Java Servlet Based - Open Source  |        Collab.Net
        Bug/Issue Tracking System     |   now hiring smart people
       <http://scarab.tigris.org/>    |  <http://Collab.Net/jobs/>

Re: sessions again

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

jon * wrote:

> Ok,
>
> I'm going through and implementing this session reload stuff in Tomcat (not
> Catalina yet since I'm currently using Tomcat).

You won't need to worry about it for Catalina, because it's already there (I'm
going to add the change you just made about unbinding any non-serializable
attributes so they don't just disappear).

> Anyway, here is a problem
> that I'm running into:
>
> Currently, the SessionManager interface does not have any way to get a list
> of all the sessions. The StandardManager does have this ability
> (findSessions()), but since this isn't part of SessionManager, so I can't
> reliably use that interface in my code, I have to code specifically for the
> StandardManager which would be bad.
>
> So, my question is this: can I add the findSessions() method to the
> SessionManager interface?
>
> Second question (which kind of nullifies the first because I won't really be
> externally using the findSessions() method if this is ok):
>
> Can I also add a method to both SessionManager and StandardManager that will
> return a Hashtable instead of a HttpSession[]? The reason is that it will be
> easier to do the serialization. I will need to create this Hashtable anyway
> from the HttpSession[] so it would be nice to just have this method in a
> re-usable location instead.
>

I don't really care what you add to the Tomcat 3.1 classes.

But, in general, why do you need to get back a Hashtable?  Just so you can
serialize the whole thing in one fell swoop?  In Catalina, I do the
serialization like this:

    Session sessions[] = manager.findSessions();
    Serialize the number of sessions as an integer
    Loop through the array, serializing each session
        individually (after dealing with the non-serializable
        attributes, of course).

and deserialization reads the counter first so it knows how many sessions to
load.  This way, you don't expose internal data structures of the Manager
anywhere.

>
> thanks,
>
> -jon
>

Craig