|
I believe if you read the Servlet specs it makes no
restrictions on the size of things that can be placed in the HTTP Session
object.
I echo everyone's prior comments about Session watchouts
and I'll add a few. Be careful of using Session information in load
balanced scenarios. If you aren't using some form of "sticky" sessions,
you can run into problems where your cached data isn't available like you think
it should be.
Also, due to the stateless nature of the web, you need to
think long and hard about assuming that something is going to be in the
session. You need to strongly consider writing code that checks the
session for information and falls back on recreating the data if it wasn't found
in the session.
Thirdly, delete items from the session as soon as
possible, you don't want things sticking around that might effect behavior
on other screens. I saw this recently on a site that stored the result set
page number in the session. If you were on page 5 of the search results
and then back buttoned to the search screen, then ran a search that resulted in
only 1 page of results, it would error out because there wasn't that many result
pages available. In short, don't do stuff like this.
m
Besides serialization and
deserialization of session data during fail over, any other downsides of using
session data against using regular caching utilities? I can make the heavy
weight data in session as transient to avoid serialization/deserializtion and
have a way to recover it in case of failover.
Particularly is it true that the size of session data
is also only limited to JVM?
Thanks!
Lei Han || Home : (248) 6149056 || PCS :
(513)6074271
| "Tom Rose"
<tom.rose@xxxxxxxxxxxx>
11/01/2005 11:05 PM
|
Please respond
to
<tom.rose@xxxxxxxxxxxx> |
|
|
To
| Lei Han/CIMG/CVG@CVG,
<users@xxxxxxxxxx>
|
|
cc
|
|
|
Subject
| RE: [cinjug-users] How much data
can session store? |
|
Lei,
Not sure about a way to limit the session size in
a particular container. However, best practice is to keep HTTPSession as small
as possible for each user. If configured for persistent session, remember it
will get serialized and stored, so from a query and store perspective the
larger it gets the slower it will be to perform these operations. When you get
into a clustered configuration, you may have in-memory session replication for
fail over, or just persisted as noted before.
So to answer you
question, you need to get familiar with what is being done with HTTPSession in
your particular container configuration. Then if the HTTPSession behavior
(persistent, replication, etc) is consistent with the behavior required for
the cached data, there is no advantage to building another cache. If the data
does not have the same requirements, then yes there may be advantage to
creating another cache. Regardless of what is chosen, you will still
have to performance profile the application to see how its behaving, and
ultimate tuning of the JVM is always a good idea.
Best
Regards,
Tom
--
Tom Rose
CTO,
i-Konect
210.568.0466
tom.rose@xxxxxxxxxxxx
Empowering people with information that Moves!
From: lei.han@xxxxxxxxxxxxx
[mailto:lei.han@xxxxxxxxxxxxx]
Sent: Tuesday, November 01, 2005
9:55 PM
To: users@xxxxxxxxxx
Subject: [cinjug-users] How
much data can session store?
How can I find out the size limit of session data
for my container?
If I write a cache utitlity, theroetically it can hold data up to
JVM limited size. How about session? If I store the data in session, what's
the limit? And would it substantially affect performance than storing it in
regular cache instead?
Thanks!
Lei Han
|