HttpSession size

I was thinking of why there is a need for reducing Java HttpSession size lately. Especially since it makes things a lot easier to deal with. I finally found a good reason. Security Large HttpSessions mean that if there is a DDOS attack or sudden spike of users would mean that the session cache will get filled up quickly. Although this can be tuned to be larger to accomodate the new users and make better use of the machine, it won't save from a DDOS attack that has the user logged on. This reason is more plausible than:

• heap size - that's just memory, we can add more as needed. And its not really that anyway since there is a separate set of memory space for session management on WebSphere
• serialization performance - this only has impact when there is session persistence, which on an unclustered or session affinity environment does not exist. Also session replication is done over the wire across servers in a cluster rather than to a central database which is what it did before.

So how do we resolve this problem of large session size?

• Pass around as request parameters and hidden fields. Makes things more complicated to develop and maintain.
• Store it in the client as a cookie. The only problem is the cookie size limit on the client.
• Store it in a database manually. This is somewhat complicated and you have serialization performance hit, but you do not have the heap size issue.
• Combine request parameters and storing in the database. This is probably the most complicated and hardest to maintain. How do we know where piece data is supposed to come from since there are two sources to look for?
• Use a rich client. You can store session data in the client side memory rather than maintaining it yourself.
• Use AJAX. You can store the session data in an XML tree in the client side. Probably complicated to set up, but should be easier to maintain. You are just limited to Internet Explorer and Mozilla based browsers.

As a preference I'd rather avoid request parameter passing as it increases the complexity of developing pages.

AJAX I think is a good approach.

However, storing data in the database is probably the easiest to develop for. Although the least performant. But its also the easiest to scale up in both development effort and server load. Most server machines now come with gigabit ethernet and fast hard drive arrays with multi CPU.

Lets say you have a 256k session object, you can basically have 4 users per MB of memory which is about 4000 per gig of concurrent users. If you allocated 1G of session space and you can afford to do so. Its all a matter of trade off, but you'd hit the ceiling faster by having large session objects.