IMHO first you should ask whether this is needed for the production version.
Will it be used in production environment or is it just to ease your
development? If the former is true then such functionality has no place in the
application.
I may be misunderstanding what you're trying to do. But anyways...
I currently just restart the JRun engine. It seems the 'cleanest' way. Also
by adding an 'if' to see if some argument tells you to reload you have just
lost a milisecond on doing that check. Multiplied by thousands of requests
times thousands of users it adds up.
As to how to handle configuration data. (I hope you mean ServletContext and
not HttpSessionContext, otherwise we're not connecting and I'm going off on a
wrong track because you may want something else (user specific configuration in
HttpSession?)). I just use a properties text file to load a
java.util.Properties object. Since I use one main servlet in delegation model
I have only one properties object. It's pretty straightforward.
dave.
"Steven J. Owens" wrote:
> Folks,
>
> So I have several servlets running under NES 3.x and Jrun, and
> they each have some data they load from configuration files. They
> only load it on instantiation, they don't need to modify it. Hence I
> didn't bother synchronizing the data. Why borrow trouble? Also,
> there's the performance hit to worry about.
>
> However, I'd like to make it feasible for some of these config
> files to be edited and dynamically reloaded, without having to
> stop/start the Jrun engine. It's fairly straightforward to add a
> little code to, when invoked with an optional argument, reload the
> configuration files.
>
> However, this once again introduces the issue of synchronization.
> I could either add the synchronization and live with the performance
> hit, or not add it and take my chances with the reload not tripping
> anything. Or is there a third option? Am I making a mountain out
> of a molehill?
>
> Given the situation, most of the usual multithreading issues seem
> moot. I'm not worried about a request getting half the wrong set of
> config variables, mostly there just aren't that many to begin with.
> There's no chance for deadlock or for threads stepping on each other,
> since only the reload would write to the variables.
>
> I could restructure the servlet so each thread gets a snapshot of
> the variables at the beginning of the request, to minimize the chance of
> getting half the variables before a reload and half after. I could have
> this snapshot check a boolean before copying, and have the reload set
> the boolean to false on starting, and then to true on finishing. It
> wouldn't be synchronized, but then again I'm not worried about many
> threads attempting to reload the config variables at the same time.
>
> I could also have the reload command load all the information
> into a second set of variables (doing all of the file access, object
> instantiation, parsing, etc) and only then swap the references into
> the servlet variables, to minimize the window of vulnerability.
>
> Are there any other issues to watch out for? Can any of these
> trip the servlet engine up and crash it? Is there a better way?
>
> On a more general note, any thoughts on good ways to handle
> configuration information in general? Using a singleton class, or
> storing them into HttpSessionContext? What's the overhead of pulling
> the variables from HttpSessionContext? Is HttpSessionContext
> synchronized? It sez here it's deprecated as of 2.1, but it doesn't
> say what, if anything, replaces it.
>
> Steven J. Owens
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
--
David Mossakowski [EMAIL PROTECTED]
http://www.dwdog.com/styk 212.310.7275
"I don't sit idly by, I'm planning a big surprise"
F U G A Z I
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
