struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: [shale] some improvement proposal for performance
Date Thu, 25 May 2006 06:21:37 GMT
On 5/24/06, Gary VanMatre <> wrote:
> >
> > the following code demo an hotswap design for file change monitoring.
> the
> > only limitation is that shall use getMap() first and once.
> >
> > map idMap = getMap(), and latter use idMap variable through an request
> > thread. you can use weaked referenced variable and threadlocal to
> improve
> > the following demo further.
> > in clay, watchdog maybe hotswapable I think.
> >
> I'm not sold on the Thread based file watch but I don't have a good handle
> on
> what types of threading are allowed.  I'll go with Craig's opinion on
> this one.

It's legal for a webapp to create threads beyond the request processing
thread(s) provided by the container, so long as they do not directly or
indirectly reference any request or response objects handed to any
particular  request.  In a JSF-based app, you also need to be aware that
component processing is *not* safe for multiple thread access, because it is
assumed only the request processing thread will access the tree.

For configuration file updating, it should be feasible to start a background
thread for this kind of thing ... but I'd like to make sure that we share
this kind of technology between Shale and SAF2.  In particular, WebWork has
some code that already exists which we can look at for this purpose.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message