Where session variable is stored in java web application

Question

1 - Where session variables is stored in java web application ? on the client or the server side ?

2 - If i put a lot of objects and variables through the session it will slow down client's requests ?

P.S In my case i use spring mvc.

Solution 1

The "session" variable consists of two pieces, a very small session identifier which is stored on the client usually named jSessionId and stored as a cookie. But, the sessionId may also be encoded into URLs.

The second piece of a session is the actual data, and it is stored on the server. Possibly in a server-side database if the your server is part of a multi-server cluster. Each session is identified by that sessionId and the client sends it with every request. That is why it is designed to be very small.

Solution 2

Simple answer is : your session data are stored on the server side.

Web browser will get only an string id to identify it's session.

In fact, spring security takes more care of session information, because if users even don't login, session may not exist at all.

When I use spring mvc only, I don't use session to store important data, because session is stored in memory only. It is designed to save data temporarily.

When I use spring security, I have to save many important things in memory, such as account data which could not be transmitted on internet, and I won't load them from database every time. So I have to choose session.

So when the server which stored login session is down, all users have logged in on this server would have to relogin to retrieve another session id.

Session is not always the best choice, because when we have many servers that use session data, I have to share the data among all servers, anyway, net IO is expensive for servers.

Solution 3

1.it stored on server 2.Session stored on server ,so the Object you set in it may also stored on server.Request only send a SessionId to server to indentify this users Session to other users Session.

Comments

[Hayi]

so if there is just jSessionId which is stored in client why we don't make all our variables as session variables and not request variable/attribute ?

[Hayi]

so if there is only an string id which is stored in client side why we don't make all our variable as session variable and not request variable/attribute ?

[Elliott Frisch]

@Aminoo Because request variable/attributes are only valid for a request, session variables are valid across multiple requests. Both are on the server (the third server "scope" is application). I recommend Head First Servlets and JSP for a more thorough explanation.

[Hayi]

no i understand servlet and jsp i just ask you if session variable got little storage at client why we don't use only session variable and not request variable which we need to load them at every request.

[Doug Hou]

There are many problems about server side session variables. The most big one is server scaleable and performance. Consider if you got many servers, and one of them down, what would happen? The session datas in this server would lost. Of course you can stored your session datas in db or memcached server, but that means all session operations triggers a net IO, that costs lot.

[Hayi]

in other word what is the drawback of using just session variable ?

[Elliott Frisch]

@Aminoo If you are in a cluster session variables must be serialized and (usually are then) written to a database. Request variables aren't. Also, the more you store in the session the slower and less scalable your application will generally be.

[Hayi]

if a server is down we can retrieve data from it i think, unless he goes on fire :-D

[Hayi]

can you detail this "the more you store in the session the slower and less scalable your application will generally be" because i ask also for this in my question

[Elliott Frisch]

@Aminoo Is it easier to lift 1 liter of water or 1000 liters of water and why?

[Hayi]

but there a strong server to lift it and if the client will have 1000 request it will be the same.

[Elliott Frisch]

@Aminoo That's what we call throwing money at the problem, for the same money the less data in the session the more concurrent sessions your application can handle (that's users). Also, the less data in the session the faster it can replicate in your cluster and generally the faster your application will perform (that's per user).

[Doug Hou]

No I'm afraid you can't get the session data, because the session data are in memory only, when the server is down, you'll lost all the data in memory.

[Hayi]

can you give example that will slow if i have lot of session variable ?

[Hayi]

sure just in memory ? if server restart so every body have to login again ?

[Hayi]

the variable are stored on disk/hard drive or memory ?

[Elliott Frisch]

@Aminoo Depends on the server and the server configuration. In memory or in a shared database (usually).

[Doug Hou]

@Aminoo yes the session data are in memory if you don't have special configuration, because that is the most effective way to load data. That is why many programmers hate server side status.

[Irfan Nasim]

if cokies are disabled on client? where then jsessionId stored? @Elliott Frisch

[Amogh]

@ElliottFrisch Our web application is deployed on 5 different servers (tomcat 7) and all these are behind LB. What we are facing is when one user get logged in and clicks on any menu its get redirected to login page again this is due to LB is sending 2nd request to other server where its session is not created. To avoid this we have enabled persistent session on LB so that once a request comes to an server it will always be given to the same server. but due to this all 5 servers are not used as expected. So is there any way out in java (Spring) like session state server in .NET.

[Amogh]

...cont. Sending jSessionId on each request will not solve this, I guess. Correct me if i am wrong. and what if cookies are disabled on client browser then how jSessionId will be stored.

[Elliott Frisch]

You use HttpServletResponse.encodeURL(String) or (if cookies are disabled) there is no session.