There are three ways of session management in n-tier applications:
- Client-side session management – The client takes care of managing the session state. This can be done using cookies or hidden form fields. Since the session state is maintained by the client this is also called as a stateless session. The session state can be restored even if the server crashes.
- Server-side session management –The session state is maintained by the server. Stateful session beans in EJB or HttpSession is used to maintain the session state. The session state cannot be restored if the server crashes.
- Database session management – The session state is stored in the database. This is a type of stateful session management in which the session state can be restored when the server crashes.
In this blog, I’m writing about both advantages and drawbacks of client-side and server-side session management.
The following factors determine whether we should use the stateless or stateful session management:
- Number of requests across which the session state needs to be maintained.
- The number of users using the application at a time.
- The size of data which needs to be maintained in a session.
Drawbacks of client-side session management
- The sites which use cookies for session management cannot be used if cookies are disabled in a browser.
- Some data such as product price can be modified in a form, if hidden form fields are used. In such cases, information can be retrieved again on the server side and verified.
- Sensitive data should not be stored as hidden form fields.
- Encryption may be required in client-side session management.
- Data needs to be resent to the client in each response. As the number of requests across which the session state is maintained increase, it can be a performance overhead.
- If the size of data to be maintained in a session is large, client-side session management is not preferred.
- The cookie size cannot exceed 4KB. Maximum 180 cookies can be created per domain.
- The value in cookies and hidden form fields needs to be stringified and it may not be possible to convert complex objects into strings. Also, the conversion from object to string and back to object can add to performance overhead.
Advantages of client-side session management
- No impact of server crash in between requests.
- When there are two or more requests across which the state needs to be maintained and the number of users concurrently accessing the application is more, then client-side session management is preferred.
- The session need not be replicated on other server if the requests are routed by a load balancer.
Drawbacks of server-side session management
- When you use stateful session beans for managing session state, then the EJB container has to manage the beans. When all the beans in the pool are exhausted, the EJB container has to activate and passivate the beans when they are used and not used respectively. This could be an overhead as the number of users and duration of a session increases.
- When HttpSession is used to maintain session state, then the number of HttpSession objects that the server’s heap has to maintain grow as the number of users grow.
- It cannot survive server crash. If the session state is lost, it cannot be reproduced. The session state can be stored in database to survive server crash.
- Large objects should not be stored in HttpSession . If you are not using Stateful Session beans then a better alternative is to use database session management.
- Session migration takes place if the request is handled by the other server in the cluster. This is an overhead.
Advantages of server-side session management
- If the number of requests across which the session state needs to be maintained is more, server-side session management is faster as the session data need not be resent to the client in each response.
If the data which needs to be maintained in a session is large, server-side session management is preferred. However, HttpSession should not store large objects.
