Thanks Craig, I can see that there is a lot I still have to learn about this area.
Where (other than the spec itself which should of course be my first stop) would be a good place to get info on these things? Its quite alarming to think that if you set a session attribute it might not be available when you process the next request, and if one sets a whole lot of stuff if the context (including the struts config objects) that they might only be available on the machine that created them! hehe Im obviously not grokking this at all. -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Monday, 18 August 2003 23:50 To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: RE: [OT]Servlet Context/Static Fields On Mon, 18 Aug 2003, Andrew Hill wrote: > Date: Mon, 18 Aug 2003 17:12:34 +0800 > From: Andrew Hill <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > To: Struts Users Mailing List <[EMAIL PROTECTED]> > Subject: RE: [OT]Servlet Context/Static Fields > > If your in a distributed environment changes you make to properties of those > static classes will not be propogated to other JVMS (or indeed other > classloaders), whereas the stuff in ServletContext should be (though Id love > to hear an explanation of how it knows when to do it!). > Propogation in a distributed app server is actually only guaranteed (in the J2EE specs) for *HttpSession* attributes, not *ServletContext* attributes. It's certainly possible for a server to offer replication of context attributes as well, but you can't rely on that to be portable. The strategy for knowing when to replicate session attributes (and it would probably apply to context attributes as well) is typically a configuration option in a server-specfic deployment descriptor. One could imagine doing it on a timed basis, or whenever setAttribute() is called again, or having some out-of-band method of signalling the server that this attribute has been modified. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
