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 22:20:42 GMT
> Returning back to the topic at hand, I see three types of class loaders
> being popular:

Not really three different classloader, but simply a single classloader
with 3 "features". Also note that the actual reloading of the session data
is done outside of the Classloader. In JServ it is within
JServServletManager since that is the appropriate place.
 
> 1.  Simple class loader - Load once, run forever.
> 
>     No timestamp checks.  If servlet is loaded, use it.
> 
>     Overall, I see this one as being the most popular.  Why?
>     Raw speed.  No file timestamp checks.  In many cases,
>     everything can be in memory with no disk accesses.

For Production Environments.
 
> 2.  Simple context flusher - When in doubt, flush it out.
> 
>     Timestamp checks on every access.  Any discrepancy, and
>     the entire context is flushed and restarted from scratch.
> 
>     Overall, I see this as the one that I would use the most.
>     Why?  As a developer, I'm changing code, and spend most
>     of my time debugging and exploring.  The last thing I
>     need to

For Development environements...I like how you didn't finish "the last
thing i need to..."...
 
>     On one hand, I certainly admire the technical solution
>     to a quite difficult problem.  And perhaps someone can
>     argue this is needed for sites which can tolerate
>     absolutely no down time.

Thanks. It was months of headaches and trying to get in contact with the
people at Sun who implemented the classloader to begin with...all to no
avail. Then, someone on the JServ list decided to help out and helped find
the solutions.
 
>     On the other hand, being basically distrustful, I know I
>     wouldn't want to open myself up to the possibility of an
>     incomplete restore on a production site - however rare this
>     may be.  Nor would I want to deal with the uncertainty
>     while debugging.

Please believe me that this case is so rare it isn't even funny. In fact,
I haven't even been bit by this one single time. Hell, I didn't even think
of this as being an issue.
 
> So, my guess is that we need to have three (or more) plug-in
> implementations available, accompanied by instructions on when one might
> want to prefer one over the others.
> 
> Question for all: am I missing any key scenarios?

Nope.

-jon


Mime
View raw message