Hi,
On our site we have lots of "session" data. On a busy day, this can exceed
500MB of objects stored in the HttpSession. Each session (client) might have
10MB or more of data in their session. I see no reason why its any big deal.
The HttpSession for each client is just a list of references to objects in
memory. It certainly doesn't slow our site down any..unless we run out of
memory. I suggest, first and foremost you have LOTS of memory for your web
servers. Memory is cheap, $200 for PC133 256MB chips (generic, but lifetime
warranty anyways). Get at least 512MB ram, if not up to 2GB of ram per
server. However, thats not to say just throw memory and don't worry about
anything. Are you removing objects from the session when your done with
them? For example, on our site..when they log in a client maintains a
"client" object that contains their profile and stuff..throughout our site.
This is because they update this at many places. However, specific areas
(tabs) create a session object that exists across multiple pages/forms,
until they get to the last page. Then we remove it. Because we use
JSP/JavaBeans (actually..we are moving to it..still stuck in solid servlet
mode right now), your JSP page uses a bean, does what ever, submits, the
logic occurs, and the next page shows up, using the same bean. Ideally, in
my opinion, you would use one javabean for multiple pages/forms that exist
across a single, overall transaction. When the transaction is complet, you
go to a page that says "Thank you" or something, and REMOVE the object from
the session. At that point, it shouldn't be used any longer...when they go
to that same tab again, a NEW object is created. In an e-commerce
shopping-cart system, you definitely will need to keep the objects across
all pages, so you can't just remove it..until the ORDER the items. Then you
remove it. When they order, the transaction is recorded in the database, and
thus if you need to redisplay it for some reason..what they ordered, etc,
you grab it from the database.
Speaking of the database, I hope your using some sort of connection pool.
That will speed up access to the database an order of a magnitude over
opening and closing connections every transaction. We have about 100 users a
day to our site, and we only allow 30 connections in the pool. This is a
fair amount..a connection is "retrieved" from the pool on a per-request
basis. We don't tie one connection to a session and hold it there the entire
time. This is NOT recommended. You'll run out of connections very quickly,
especially on a high-load site.
One last thing I can think of...use caching for results and such. For
example, we use a Hashtable with fields for quries. The first time a "mask"
is set, the search is performed and the results come back as a Vector. We
then "cache" that return and the mask that got it. From then on, if that
same mask is asked to be used for a search, we just return the cached
results. Pros and Cons exist for this. First, if you have "other" users that
could be updating the same table, maybe adding rows, removing rows,
modifying colums in that same result set that is cached..then the "cache"
result may not be reflective of an updated table in the database. So, I
would say employ some sort of time check. If the same mask is used to query,
and a cache exists, if its been longer than say 1/2 hour, or 1 minute,
etc...(depends on the volume of the site and the queries using the same
mask), then you still go to the database and store the new results in the
cache.
Anyways..hope that helps a bit.
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
