struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@gmail.com>
Subject Re: ServletContext, Initialisation, & Distributed Environments
Date Thu, 16 Dec 2004 11:50:15 GMT
Intermixed.


On Wed, 15 Dec 2004 19:46:07 +0000, Adam Hardy
<ahardy.struts@cyberspaceroad.com> wrote:
> On 12/14/2004 12:32 PM Andrew Hill wrote:
> > According to the sevlet spec: "context attributes are local to the JVM
> > in which they were created. This prevents ServletContext attributes from
> > being a shared memory store in a distributed container".
> >
> > What Id like to know is how this affects configuration information I
> > load in a PlugIn or in a servlets init method when the application
> > starts up. If there are multiple JVMs, each will get its own instance of
> > the same servlet (which presumably is marked as load on startup), so
> > will init be called on each of them? or just for one machine?
> >

In a distributed environment, there will be a physical instance of the
ServletContext for your webapp (including all its attributes) per
server instance.  If all you ever do in servlet context attributes is
cache unchanging data at webapp startup time, then every server
instance will have an identical copy, and it won't matter what server
instance you hit for a particular request.

The warning in the spec language, though, covers the case where a
ServletContext attribute is modified during the lifetime of the
application.  Any such change on one server instance is *not*
guaranteed to be propogated to other server instances (although some
containers might offer such support as a value add feature; depending
on this would not be portable).

In addition to per-server instances of ServletContext, you also get a
per-server instance of ActionServlet (or any other servlet you've
defined in web.xml).  As with servlet context attributes, any changes
to the instance variables in this servlet instance are not propogated
to other server instances.

> > Im guessing the former, as the latter seems dodgy, but Id like to hear
> > it from someone who actually knows for sure.
> 
> Well I've never had to cluster any application but since no-one else
> answered, here's my input, since I'm interested.
> 
> Correct me if I'm wrong, but doesn't the servlet context contain the
> request, the response and the session? I don't know what generic context
> attributes are. I guess your answer lies therein.

The servlet context does not contain direct references to requests,
responses, and sessions, because there are multiple instances of those
-- but the servlet container certainly has references to the relevant
things.  A couple of interesting notes:

* A single request from a single client to your cluster of
  distributed server instances exists on *one* server
  instance only (the one that your load balancer directed it to).

* A single session from a single client must also exist
  on only *one* server instance, and the distributed cluster
  is required to forward all requests for that session to the
  same server instance.  It's legal for the container to migrate
  a session from one server instance to another, but only
  "in between" requests.  The reason for these semantics is so
  that session attribute changes made by one request *are*
  instantly visible to any other request for the same session,
  which is exactly the way things work in a non-distributed world.
> 
> I would also guess that each servlet container calls the init method on
> every servlet.

Yep.

> Do you have a clustered test environment to test it with
> some logging statements?
> 
> Adam
> 

Craig

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


Mime
View raw message