@cool_dude_prav: Let's get a couple of things straight first. EJB is the business component of the J2EE specifications, providing the business logic tier of the enterprise application. If you are talking about simple session management, then why should anyone even bother with business models for each and every site simply to provide more security. Plus, contrary to what most people think, cookies aren't all THAT bad as some people make them out to be.
Like GNUrag pointed out correctly, why get into Java at all for a simple site that can handle cookies over SSL without any other overhead? Why waste server resources at all?
However, if you are talking about general session management in J2EE, especially JSP/servlet/EJB powered portals like Citibank's or Amazon's online portals, etc. then the argument is a little bit more complex.
If you look at J2EE best practices, its recommended that if you are going for client-side session state, then the cookie should hold minimal information, since its easy for viewing/editing the cookie on the client. There are more problems to it, for example, that if the user disables cookies, the enterprise application cannot use cookies to maintain the session state. Also, since the cookie is shared between instances, the user can open another browser window to the portal (sharing the same cookie) and the enterprise application would be totally confused and there MAY be unnecessary conflicts if the coding is not 100% proper.
However, its not really a joke maintaining session state on the server. You can use the HttpSession interface and use it to store session state. The advantage is that its highly scalable and of course, a lot more secure. However, most enterprise app portals use a number of servers across which all the components are stored and depending on how much load is there on the portal and the number of hits, which may go into the millions per day for some portals. You will need to use replication across the servers to make sure the user gets a steady, unified experience. Its obviously better to store session state on the server, and most portals do use a combination of safeguards such as session timeouts and storing state on the servers instead of dumping all data on the client. For example, the state for Amazon's portals maintained on the client side is minimal. All your information is stored and accessed server-side. If you want to know more about this, check the Amazon implementation whitepaper at Java.Sun.com.
This, is however, not feasible practically for all servers, only high-volume, high-risk servers, such as online banking, etc.
@GNUrag: EJB or Enterprise Java Beans is simply the business logic tier of an enterprise application.
No way connected to simple session management unless its for enterprise apps.
