"Nelson, Laird" wrote:
> This probably ultimately concerns servlets, but it applies to the session
> scope of JSP pages as well.
>
> I've heard from several sources now, who have not gone into details, that
> relying on the builtin Session object will get you into trouble when your
> high-volume web application begins getting pounded. Specifically, the
> problems referred to had to do with load balancing (presumably there would
> be a problem matching outgoing responses with their incoming requests).
>
There is nothing particular to the HttpSession object that "gets you into trouble"
or not. The thing you have to design for is having enough server resources
("supply") to meet the expected request volume ("demand"). The reality is, of
course, that demand comes in spurts -- so you are really planning for how big a
spike am I willing to commit to supporting, with reasonable response time.
Once you know that, you know how much "supply" is needed. If you can make it
available in a single server environment, running in a single JVM, then you don't
have to worry about any of this stuff. If you need to run multiple back-end
servers to satisfy the demand -- in the terms of the Servlet 2.2 spec, your app is
declared to be "distributable" -- then you need to understand how your particular
servlet engine platform deals with session management. The actual behavior is in
the realm of value-added features of a particular implementation, not in the specs
themselves.
>
> Can anyone comment on these problems in general? Should I assume that I
> will have to write my own centralized session management so that I can bring
> up more than one JSP engine at a time?
>
Grossly simplifying, there are several possible strategies that a servlet/JSP
engine implementation can take to deal with load balancing and associated session
management. Some common ones are:
* Distribution is not supported at all -- the application's
servlet context (and therefore its sessions) must only
run on a single server, in a single JVM.
* Load balancing is supported for non-session-related
activities, but not for session-related activities. This
isn't particularly useful for the discussion at hand, but
is pretty easy to do.
* Non-session related requests are load balanced across
the back-end servers, but once a session starts, all
requests to that session are always sent to the same
server. This is the stategy that Apache JServ, for example,
supports. It works because the load balancer modifies the
session identifier to include a server identifier, and always
returns requests for that session to the same server.
* Sessions can be dynamically relocated across back ends
as needed by the servers (perhaps in response to a server
failure, or a surge in demand on the server being used for
that session right now).
The 2.2 servlet spec does refine the servlet/JSP developer's responsibilities a
little bit. If you do not mark your application as being "distributable" in the
deployment descriptor, you can store anything you like in the HttpSession -- and
the servlet container is not allowed to move your session from one server to
another.
If you do mark your app as "distributable", you must ensure that any user objects
you store implement the Serializable interface, and the engine has the option --
it's not required to support this -- of moving your session from one server to
another. However, at any point in time, one and only one server is responding to
to requests for that session, so your servlets can't really tell that you got
moved. As long as you make your user objects implement Serializable, and you do
the normal synchronization and locking needed to run even in a non-distributed
environment, you shouldn't have to worry much.
Before starting to consider writing your own session management, I would turn your
question around, like this (personal suggestions, others will have differing
opinions):
* Do I need multiple back end servers at all? If not,
there's no need for distributed support. In many
environments, it can be cheaper to throw hardware
at problems like this (you have to buy a pretty big
multiprocessor box with lots of memory and disk
to even spend $10k on a server nowdays).
* Which basic flavor of distributed / load balancing
support do I need? If sessions are relatively short
lived, and tend to have pretty level resource usage
requirements, you may not need your server to be
able to migrate a session from one server to another.
On the other hand, this might be very important --
it's a very application sensitive issue.
* Can I find a servlet container provider that supports
the level of distribution / load balancing support that
I need, for a price I can afford? You'll find that the
more sophisticated load balancing / session migration
techniques tend to be features of the more expensive
application servers, rather than the low-cost / no-cost
servlet engines, but feature suport changes all the time.
* Only if you have to should you consider writing your
own distributed session management stuff. Remember --
writing server level code is a distraction from your main
goal of developing an application, and you're going to be
stuck with supporting and enhancing this part of the
code, as well as the regular app part.
Even in a non-distributed environment, your servlets and JSP pages have to be
aware that they are running in a multithreaded environment, and deal with the fact
that multiple requests for the same session can happen simultaneously. One of the
goals of the servlet API is that the application developer should have to do
little, if any, in addition to make their apps operate correctly in a load
balanced environment -- the mechanics of making it work correctly are delegated to
the servlet engine instead. Of course, the servlet engine's distributed session
support can have bugs in it, but that's a support issue with your vendor, not an
application design consideration.
>
> Cheers,
> Laird
>
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
