Anirban Sharma wrote:
> Craig,
>
> A few questions/comments below:
>
> Craig McClanahan wrote:
>
> > If you look inside my apps, you'll see the following design pattern all over the
> > place:
> >
> > * JSP page contains an input form. The values
> > are pre-filled-in from a session bean that contains
> > application default values the first time through,
> > or the most recent inputs after a validation error
> > (see below for more info).
>
> Question: Do you extract this information from the HttpSession? I was
> reading an article where they were saying that stuffing too much
> information to Sessions may adversely effect the scalability of a high
> traffic site. Is that true?
>
Yes, I store a bean in the user's session containing the answers for the current form
they are working on. The actual bean used is different for each form (because the
properties for a form bean need to match the fields on that particular form) but I'm
only keeping one of them, for each active user, at any point in time.
Scalability is an issue with several dimensions. Like most computing problems, the
impacts of a particular approach vary depending on which bottlenecks you hit first.
The most immediate scalability impact of sessions is memory usage. This has a direct
impact on application design, because you have to decide how much stuff to cache per
user. Keeping the answers for a typical form is probably a few hundred bytes of total
occupancy (essentially a non-issue at today's memory prices). Keeping a million-row
result set for each user (so that you can page through the results) is probably not a
good idea :-). I've got one app running on a machine with a gigabyte of main memory
-- we cache a LOT of shared stuff (not per-user, but the same basic principles apply)
from the database to speed up subsequent queries -- and didn't have to sell my
first-born son to afford it.
The second bottleneck you might hit is CPU performance. You can throw money at this
(again, not a whole lot at today's prices) by going to faster processors or
multi-processor machines, but at some point you will outgrow the performance
capability of a single server, and need to distribute the processing. Some
application server environments support session migration between servers -- the
amount of time this takes is obviously dependent on the amount of data you store in
your sessions. Distributing sessions across machines helps you on both the memory and
CPU usage fronts -- each server only needs to worry about a subset of the overall
population. For servlets, the 2.2 spec mandates that, at any given point in time, all
requests to the same session must go to the same machine, so the amount of user data
in your session matters only when the app server decides to migrate you. (The other
dependency is that you must store only Serializable objects in a distributable
session.)
Other bottlenecks, such as database transaction rates and network capacity, are
actually a place where caching stuff in user sessions can really help. In the
application with the gigabyte of memory, our tests showed a 15x to 20x improvement in
response time, primarily due to the fact that the bottleneck we ran into was network
performance between the web app server and the database server. Caching reduced the
number of network messages required, so we happily bought the extra memory -- it
translates directly into an ability to support more paying customers in the web
application (i.e. scalability) on the same server platform.
The last point illustrates something very important -- how much to cache in user
sessions is very application dependent. Web apps are no different than other
interactive apps in this respect, except that (on an Internet app at least) the number
of possible simultaneous users is unbounded unless you institute limits on the number
of concurrent sessions. If caching stuff lets you avoid other bottlenecks (as it did
in my case) then using sessions improves scalability, rather than harming it. If it
doesn't, then don't do it. But there's no absolute "good" or "bad" here.
> > * Form submit goes to a servlet (I tend to
> > use a single servlet per app, others like
> > a servlet per input form).
> >
> > * Servlet dispatches to the business logic
> > responsible for processing this form.
>
> We are starting a web application development and we plan to use
> Servlets that will dispatch calls to the already existing EJBs for
> business logic processing. The stateless session EJBs fit nicely with
> the HTTP request/response paradigm.
>
Yep. The J2EE application development paradigm is pretty much this approach. Note
that EJBs also let you deal with scalability issues on the back end without having to
modify your front end applications -- it's your EJB server's problem.
>
> > * The most recent set of form inputs are
> > saved in the session bean (used in the first
> > step) in case a validation error is detected.
> >
> > * If the business logic detects a validation
> > error, it stores an error message bean and
> > forwards control back to the original JSP page
> > containing the form. The form can then be
> > redisplayed with the previous inputs in it,
> > along with the error message. The user
> > only needs to modify what needs fixing rather
> > than starting from scratch.
> >
> > * If the validation checks all pass, the business
> > logic performs the required function, stores any
> > results in session beans, and forwards control
> > to the next JSP page to display the results.
>
> I agree with your mixed approach because:
> 1. It is awkward to write a complex HTML page using out.println() in a
> servlet.
There are actually some pretty nice object oriented approaches to doing HTML output in
servlets. This is one of the things you can use implementations of the HTML Document
Object Model (DOM) for (see http://www.w3.org). See also things like the htmlKona
library that is (or was?) part of BEA/Weblogic's Tengah server, the Element
Construction Set (at http://java.apache.org) that implements essentially the same
functionality in an open source package, and numerous similar endeavors by others.
Since servlet technology predated JSP, there's a lot of apps that use the
servlets-generate-HTML approach. However, I personally never plan to write another
one.
>
> 2. If my JSPs have too much Java code in them, then they have more then
> just presentation logic.
>
And that extra Java code is usually business logic, which makes it harder to change
just the user interface, or just the back-end business logic, without impacting
everything.
>
> just my 2 cents..
>
> Anirban
>
Craig
===========================================================================
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
