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
