commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Soaring Eagle <comfortable.n...@gmail.com>
Subject Re: Configuration - Reload Strategy in j2ee containers
Date Wed, 06 Apr 2005 19:33:13 GMT
> Since the container doesn't have the control over the life cycle of the
> thread that takes care of the reload, say next time the container
> starts, you don't want the reloading to take effect not all, you'd have
> to figure out a way to kill that thread....?

In my unit tests, when I request the container to shutdown, my custom
thread also shuts down.

> Plus per the email Emmanuel sent, commons-configuration seems already to
> have a built-in mechanism to do the periodical reload without spawning
> any thread....

If I understood that email correctly, the reload strategy basically
loads the configuration file each time any configuration is asked for.
That is great - however, for various reasons (mainly small performance
gains), I prefer to load configuration through a singleton class -
effectively caching all configuration. when applications require
config data, they get it from the in memory singleton cache. A
background thread of this singleton class checks for changes at
regular intervals and refreshes the in-memory configuration.

On Apr 6, 2005 2:57 PM, WANG Qingtian <qingtian.wang@gmail.com> wrote:
> Soaring Eagle wrote:
> > Hello all,
> >
> > In an app we are doing, we use commons config to load properties and
> > use a threaded class to do the reload every few seconds. this is then
> > packaged as a part of a j2ee application. When application code is
> > referenced for the first time, a thread is started and this thread
> > checks for modifications at intervals. Though the J2EE spec does not
> > allow a developer to start threads, this seems to work well for me.
> 
> Since the container doesn't have the control over the life cycle of the
> thread that takes care of the reload, say next time the container
> starts, you don't want the reloading to take effect not all, you'd have
> to figure out a way to kill that thread....?
> 
> Plus per the email Emmanuel sent, commons-configuration seems already to
> have a built-in mechanism to do the periodical reload without spawning
> any thread....
> 
> 
> >
> > The other option would be create a java application class as the
> > configuration wrapper (containing a main method) and to start that
> > class as a "startup" class in the J2EE container.
> 
> That'll work until the time comes when you want switch to a container
> that doesn't offer a startup/shutdown class. Once in a blue moon you'd
> want to switch containers, but still....
> 
> 
> >
> > Please share your views on this type of design.
> >
> > Thanks
> > Eagle.
> >
> > On Apr 4, 2005 5:47 PM, WANG Qingtian <qingtian.wang@gmail.com> wrote:
> >
> >>Hi,
> >>
> >>Is the reload strategy implemented by creating a thread that
> >>periodically checks the time stamp of the configuration file? If so, how
> >>do I make sure that thread is started/stopped properly when I use it in
> >>a j2ee container? Like, will the thread be killed when I shut down the
> >>web/ejb container? What is the "best practice" of using "configuration"
> >>in a j2ee container?
> >>
> >>Thanks a lot for your help!!!
> >>Qingtian
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message