tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j..@clearink.com
Subject Re: Servlet reloading?
Date Sat, 12 Feb 2000 21:50:25 GMT
> 
> > Yep, that's what I was afraid of.  IMO, it would be better to lose all
> > session objects on a context reload than lose some session data.  The
> > downside though is that if I arrange for everything to be Serializable,
> > then having this behavior would be really slick.  Maybe this should be
> > an optional behavior that can be turned on?
> 
> Plus - what if you store a  database connection or another object that is
> very complex and you have no control on it's source ? 

IT DOESN'T MATTER! Dude, you are not serializing in order to "save" the
object, you are serializing in order to just associate the object to a
different instance of the classloader. READ MY SOURCE CODE.

This code is only executed in a development enviroment anyways because in
production, you should turn off automatic class reloading.

> I think Jason is right - it's very dangerous to have unpredictable
> behavior, i.e. have objects that disappear or code executed "magically" 
> ( like writeObject or constructors ). If I mark a context as
> "non-distributable" probably I mean it, and probably I know that my
> session objects are not "serialization-friendly".

HELLO! It is not unpredictable if it is documented within the server.
On top of it, adding a single logging line to say that that object has
not be carried over is not a big deal. You don't have to worry about
writeObject or constructors...all you have to do
is have your object implement serializable. This isn't that big of a deal
and is a hell of a lot better than what we currently have, which is
absolutely nothing.

If you noticed, I even attempt to call valueUnbound on the object if it
doesn't implement serializable and it does implement
HttpSessionBindingListner. Thus, there is a good chance that that object
will be dealt with without issues.

May I also add that all the commercial servers that I have dealt with in
the past appropriately apply this exact same behavior (Weblogic and JRun).

> Yes, it's not difficult to implement it in tomcat ( assuming somebody has
> the time or wish to do it, and I don't !), but the "deterministic"
> question remains. 

It isn't that difficult because I have already done 100% of the hard work
for you. All you have to do is add that code into the location where the
classloader will get re-instantiated.

If this functionality is not eventually placed into Tomcat, I will NEVER
use it. Heck, this is the *main* reason why I haven't even used it yet
to begin with. That is not meant to be a threat. Here is why...

Turbine *depends* on this functionality being present because I store
whether or not a user has logged into a session variable. If every single
time I recompile my classes during development requires me to log back in,
I would never get any work done.

Lastly, I have yet to hear a complaint about this functionality.

-jon


Mime
View raw message