We are almost at the end of our development project. some how we have land up in a situation where our session size is shooting beyond 6K. Can you guys suggest some solution. Since we cannot afford to make any major architectural changes, i shall be intrested in some side tricks.

Currently i have tried to zip the whole session which is bringing down the size less than 2.3K. May i know if there are any impact of this trick or will it be costlier than making db calls from each page.

Performance would presumably be degraded.
Just curious, how are you planing to zip a session??

Hi Rajesh,

It depends on what problems you're trying to avoid. 6KB is already a fairly small session size.

If the concern is related to the JVM heap size, then simply create more JVMs and spread out the sessions (easy to do if your application is already clustered). If your application isn't clustered, you may want to consider doing that.

If it's physical memory consumption that you're worried about, then you've got the tradeoff between using more memory (doing nothing), CPU (compressing) or I/O (storing to disk or database). If you need to compress, you're probably best off using a lightweight compression algorithm like Huffman (which I believe is supported by java.util.zip). If you have hooks into the session serialization-deserialization process, you could use a more compact serialized format than standard Java serialization (which would reduce both CPU and memory usage). My guess would be that efficient compression would be similar speed (and better scalability) compared to persisting to a database.

If the issue is clustering overhead (larger sessions requiring more CPU for serialization and more network resources as well), you might want to mark certain session attributes as non-clustered if your session management solution provides that option.

Jon Purdy
Tangosol, Inc.