wood burning stoves 2.0*
The moose likes JSP and the fly likes session info Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSP
Bookmark "session info" Watch "session info" New topic
Author

session info

Ajith Prasad
Ranch Hand

Joined: Aug 22, 2006
Posts: 66
How much information that a session can store?
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60780
    
  65

All of it.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Rusty Smythe
Ranch Hand

Joined: Aug 09, 2006
Posts: 93
Originally posted by Bear Bibeault:
All of it.


Even the stuff you don't need
Scott Johnson
Ranch Hand

Joined: Aug 24, 2005
Posts: 518
How much information that a session can store?


Depends on how much memory is available.

Like Bear said, you can store as much as you want. But storing a large amount of data in the session does not scale well and is not recommended.
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

Asking how much data can be stored in a Session is like asking how fast your car will go if it's dropped off a cliff. There's probably a correct answer, but you've really got to wonder why the question is being asked.

The HttpSession is the worst place to store data. The only problem is that it is better than most of the other options. Keep the data in your HttpSession to a minimum. If you're storing lots of data for a user, you might want to create a temporary database table and store the information about users there. Just don't fall into any traps that will minimize the workload ability of your server.

20K is way too much to be putting in an HttpSession in a typical app.
[ August 27, 2006: Message edited by: Bear Bibeault ]
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12761
    
    5
The HttpSession is the worst place to store data.

That is a dangerous generalization. Statements like that lead beginners to all sorts of bizarre configurations because "I heard that sessions are bad." We seem to spend a lot of time on these forums straightening out tangles that people get into because "I heard that...."

The proper questions to ask are:
What is the lifetime of the data?
What is the scope of the data?

Then match your design to the answers.

Bill
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

Everything William just said...
Plus

20K is way too much to be putting in an HttpSession in a typical app.


Without knowing anything about the original poster's application, it's traffic, and it's intended goals, nobody can say whether 20k (or 20 megs for that matter), is too much or too little to be stored in session.

In a low traffic site caching data in session (especially if that data requires expensive dabase queries to produce) can greatly improve application performance.


Java API J2EE API Servlet Spec JSP Spec How to ask a question... Simple Servlet Examples jsonf
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

You're right, I'll be remiss about being too negative on the HttpSession.

My issue with 20K sessions is very much WebSphere related, and especially related to heavy workload environments.

With WebSphere, especially with Persistent Sessions, the app server writes all session data to a centralized database, so that if one app server goes down, all othet app servers pick it up. So, if you're reading alot from one database table, and then throwing it in the Session, WebShere is then writing it BACK INTO a DIFFERENT database table. That's alot of writes.

The other big thing is the fact that WebSphere writes session data into 4, 8, 16 or 20K blocks in the database. As a result, if you go over say 20, to 21k in an object graphy, now you've got two different blocks to pull memory out of, which delays performance even more.

Every J2EE performance problem I've ever run into was solved by 1) fixing HttpSession bloat, 2) fixing database connection usage or 3) implementing lazy loading. I've just been bitten too many times by HttpSession objects, and I get a little weary.

But indeed, workload, application complexity and other factors are important when considering HttpSession size.
Ram Gokul
Ranch Hand

Joined: Oct 07, 2005
Posts: 85
Hi,

1. Is there a way to programatically monitor the session storage and how much data is getting stored as application progresses. ?

2.As per last post , can you please elaborate how did you solve the DB usage connection w.r.t performance issues.

Thanks
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

Heh...I think this is what earlier posts were warning about, especially with regards to my snide little comment about HttpSessions - this conversation can go into many wild directions, and now we're getting into Session performance.

I'm a WebSphere Dude, and I know that every Friday I'd run my application through Resource Monitor which can tell you how many objects are in your sessions, and how big those objects are. I always like to keep an eye on those things.

Programatically, you can use an HttpSessionBindingListener (I think that's it) to fire off every time an object is placed in a session. You can run a routine here that can loop through all the objects stuffed inside a users session, and inspect them any way you might instapce a normal chunk of Java code. The great thing about the listener is it can be enabled when you want it to be, and removed when you want it to. Aren't pluggable interfaces great?

As far as overcoming HttpSession bloat? You really have to know WHY your sessions are becomming bloated, and why it's a performance issue. Sometimes, this forces you to do bad things, like code based on how your hardware does session management, which is an absolutely awful thing to do.

One "design pattern" I see is people taking large data that would go into an HttpSession and using a temporary database table. This eliminates the use of the Session service to store the temp data, and allows the developer to control access. But again, this is a slippery slope - the whole point of the HttpSession is to stop developers from having to do this. Sometimes though, for performance reasons, it's a must.

See - I told you HttpSession objects were a problem issue.
[ August 28, 2006: Message edited by: Bear Bibeault ]
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12761
    
    5
It is really tricky to even talk about the "size" of a session in memory, as opposed to the size serialized on disk. Suppose you have 110 users each with a session having a reference to the same 10000 character string. The "size" is not 110 x 10000 x 2 bytes because the sessions hold only a reference.

Bill
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60780
    
  65

I think that any blanket statements regarding "session are good/bad" should be taken with a grain of salt. There are too many vairables to make any such statements.

As with many other aspects of engineering, a decision based upon the merits of each situation is warranted.
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

I'm crying uncle here.

Just to note what I said:

"The HttpSession is the worst place to store data. The only problem is that it is better than most of the other options."

I said it's the worst, but it's also better than all the rest. It was supposed to be tongue in cheek. There are benefits and drawbacks to every technology.

Regards,

-Cameron



 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: session info
 
Similar Threads
Alternative to Cookie?
Field set in action method coming null in JSP
Session problem in NetBeans
Advice on persisting complex state across multiple server trips
ASP