struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: Dynamic configuration?
Date Thu, 19 Sep 2002 20:42:06 GMT


On Thu, 19 Sep 2002, Joe Barefoot wrote:

> Date: Thu, 19 Sep 2002 13:28:36 -0700
> From: Joe Barefoot <Joe.Barefoot@motiva.com>
> Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> Subject: RE: Dynamic configuration?
>
>
>
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > Sent: Thursday, September 19, 2002 9:11 AM
> > To: Struts Users Mailing List
> > Subject: RE: Dynamic configuration?
> >
>
> <snipped>
>
> >
> > The real problem is that the Struts support for dynamic configuration
> > changes in 1.0 was pretty half-baked, because it was trying
> > to do a job
> > that only the container can do correctly.  It also caused performance
> > issues, because you had to lock all the HashMaps that represent the
> > configuration data (in 1.1 they can be accessed safely from multiple
> > request threads, because they are not being modified).
>
>
> I assume you mean only when the configuration data was being modified?
> This doesn't seem like a huge performance issue if you're only modifying
> the config at runtime very rarely.
>

Rule #1:  Java collection classes like HashMap are not thread safe.

Rule #2:  Struts uses HashMaps to store the configuration data.

Rule #3:  The only way to access HashMaps safely in a multithread
environment is one of the following:

* Ensure that the HashMap is not modified during execution (that's
  what Struts does with the freeze option).

* Synchronize on EVERY access -- both reads and writes.

It's not good enough to synchronize only on writes -- all that does is
guarantee that a read happening at the same time as a write will get
corrupt data.

> So, you can't reload your struts-config at runtime anymore in 1.1?
>

Reload the app itself, using your container's facilities.  Among other
things, that will cause the configuration information to be reread.

Craig


>
> >
> > It would be feasible to re-implement the o.a.s.config beans
> > so that they
> > did all their lookups dynamically in a database, but that's
> > going to have
> > a pretty huge performance hit.  Some sort of caching would
> > still be the
> > way to go if you try this.
> >
> > > Any ideas?
> > >
> > > Thanks,
> > >
> > > Kevin
> >
> > Craig
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message