session info

[Ajith Prasad]

How much information that a session can store?

[Bear Bibeault]

All of it.

[Rusty Smythe]

Originally posted by Bear Bibeault:
All of it.

Even the stuff you don't need

[Scott Johnson]

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]

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]

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]

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.

[Cameron Wallace McKenzie]

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]

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]

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]

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]

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]

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