So it makes sense to go into what "disruption" means. I'm not 100% sure
about the following, it would be good if a tomcat heavyweight would
confirm/refute what I say.
When you initiate a webapp reload, Tomcat waits for requests that have
already started processing to terminate. This ensures that people who
accessed your app just before the webapp get a complete response. Once
that's done, the application is reloaded and your servlets' init methods are
called if necessary. During this time, incoming requests aren't denied, they
are just paused until the reload is complete.
So the only disruption people see is your application freezing up for the
time it takes to reload (which is going to depend on what you your
initialization consists of). No ugly server unavailable errors or anything
of the sort.
If you don't like the idea of your app freezing, think about this. Rereading
environment params without reloading has its own risks, namely potential
race conditions. Imagine you have 5 parameters, and requests are coming in
as you are reading these in and initializing your webapp. A request might be
handled while 2 params have been read, but 3 still contain the old values.
If you start to think about locking/synchronization to solve this you're
definitely better off just using Tomcat's reload mechanism.
So my answer would be, trust Tomcat's reloading process unless you
absolutely want to avoid your webapp freezing for the time it will take for
it to init (this depends on the webapp). If you want to do your own
"reloading", think long and hard about potential race conditions (which will
occur in all except the simplest cases).
Again, all this should probably be verified, you can set up very simple test
cases with a JSP that sleeps, etc.
Shay,
I think you made a good case for keeping app vars in web.xml (i.e., seems
pretty apparent now that's where they belong).
Thanks for taking the time to respond. I sincerely appreciate it!
Eric P.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
