Hi Eric. On Wed, Jun 30, 2010 at 9:20 PM, Eric P <eric.maill...@gmail.com> wrote:
> Shay, > > Forgive all potential newbness in my responses below. I'm still learning > this stuff. > > No worries for newbiness, your responses all make sense. > > Shay Rojansky wrote: > >> Hi Eric. >> >> Would making your servlet reload all application vars not be akin to >> simply >> reloading your servlet altogether, by changing context/init params in your >> web.xml or context.xml? >> >> > Do you mean "reloading your 'application' altogether"? If so wouldn't that > cause disruption to users currently on the app? This disruption is what I'd > like to avoid. 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. > > If you really want to avoid an application reload, why not just have your >> app read its values from a properties config file instead of a DB? It >> would >> be much more lightweight and standard. >> >> > That's an idea. But wouldn't file I/O every time a servlet needs an > application value be way more expensive than storing settings in a record, > reading and setting them to the application scope once, and only resetting > these vars manually when needed? > I wasn't proposing to perform I/O and parse the properties file upon every request, simply to parse it once upon init and load it into application-scoped vars. This is exactly the same as what you were planning to do, except that instead of pulling the values from a DB record you pull them from a properties file. Note that using a property file will almost surely be faster (and not to mention simpler) than a database, as connecting to a database usually means network activity, authentication, etc. It would also make changing those values easier - editing a properties file is more straightforward than a database with its schema. But at the end of the day, it all depends on your app. If you already have everything in your DB and it makes sense to have those config values in there too, why not. > > Is this standard documented somewhere? > What exactly? :) > > Thanks... I appreciate the ideas. > Eric > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
