tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: 'distributable' web applications
Date Fri, 11 Aug 2000 16:26:14 GMT
Marcus Crafter wrote:

> Hi All,
>         I've been reading through the Java Servlets 2.2 specification,
>         searching for more information about servlets that are tagged as
>         'distributable' in the web.xml.
>         Unfortunately the specification is a bit thin when it comes to what
>         this actually means.
>         Unless I've missed something (please let me know if I have) it only
>         lightly touches on the subject, saying that a servlet marked as
>         'distributable' can only be instantiated once per servlet definition,
>         per VM (unless the SingleTheadModel is used), and that it tells the
>         servlet container that the servlet has been 'programmed appropriately'.
>         So, from a developers perspective, what does this 'properly
>         appropriately' business mean ? What specialities does one have to take
>         care of if they want to declare their servlet as 'distributable' ?

>From the developer's perspective, there are only a couple of important issues you
have to worry about, beyond all the usual concerns about programming

* All session attributes must implement the
  interface.  The container has the right to throw
  if you try to store a non-serializable object.

* You cannot assume that changes made to servlet context
  attributes (i.e. application scope beans in JSP) are propogated
  across all your JVMs.

Beyond this, you need to be aware that the servlet container has to obey
restrictions -- the most important of which is that if you are using a
session, all
the requests that go to a single session must be served by a single JVM
In other words, the session can only be moved (if your container
supports that
functionality) "in between" requests.  What this means to you is that
you can count
on session attributes you stored being visible to all requests for your
session --
you will not ever be in a situation where request #1 to a session goes
to server A
while a simultaneous request #2 to the same session goes to server B.

Of course, your container has to actually support distributable
applications for
any of this to actually be helpful, but programming as if you were going
to be
distributed (even if it is not going to start out that way) gives you
some upward
scalability options in the future.

>         Cheers, hope everyone has a great weekend.
>         Marcus

Craig McClanahan

View raw message