Saving data to session in JSF

Question

I am new to the world of J(2)EE and web app development but am quickly navigating my way around it and learning a lot. Every day is a fantastic voyage of new discovery for me.

I am currently working on a project in which I am using Visual JSF Woodstock on Glassfish v2. I am pretty new to JSF also.

There are times when I need to save some objects (say MyObject for instance) between requests. And from what I have read and understood so far, I need to be using sessions to save these objects between different requests. So far so good.

Exactly how to do this is where my concern lies. I know that in JSP you can use the session.setAttribute("myObj", myObject) which would save the object at client side using cookies or url rewrites or hidden form variables.

On the other hand, in JSF I use Session scoped beans, say SessionBean1 for e.g., and save objects as SessionBean1 properties (e.g. SessionBean1.setSomeOjb(myObj)). Is this the right way to go about with this?

I am guessing that doing it this way will result in increased memory utilization at the server end since each request will create a new instance of the session scoped bean, SessionBean1 plus the memory utilized by the saved myObject instances in SessionBean1.

I have read that you can use FacesContext.getExternalContext().getSession/getSessionMap() which would save session variables at client side.

So which method would you suggest that I use - the session scoped bean or the sessionmap to save objects for access between requests for a session?

Thanks.

Answer 1

In general Java EE Web Apps tend not to expect to save session data client side. You're right to be concerned about session bloat on the server side, a common problem seen is to have huge session footprints which can cause significant resource and performance issues, and can be especially in clustered environments.

I'd like to know where you see

I have read that you can use FacesContext.getExternalContext().getSession/getSessionMap() which would save session variables at client side.

I believe (correct me on this point) that this simply gives access to the HttpSession object, on which you can then use the same

 session.setAttribute("myObj", myObject) 

this does not in itself send the object back to the client, it's held in the server and keyed by some session identifier, usually passed in a cookie.

Now there are two other techniques: you could explicitly choose to put data into a cookie of your own manufacture - the servlet APIs that you can access from JSF or JSP would let you do that, or you can use hidden fields on your forms, and hence pass aorund session data.

But consider this. A rule of thumb on the App Server I use is that HttpSession of the order of 1k-4k tend not to be a problem. Larger than that (and I have seen sessions of measured in megabytes) do stress the infrastructure. If you were concerned about sessions of that size would you expect to send megabytes of data in a cookie or hidden field back to the browser on every request? Even 1k-2k is probably a bit big.

So recommendations:

1. Keep it simple. Use the Session API, or its JSF manifestation.

2. Keep the amount of data in the session under control.

Added in response to question about clustering:

Typically, in a clustered environment we have session affinity, so that requests are sent back to the same cluster member. However we still need to consider the case (perhaps if a cluster members fails) when the request goes to a different server.

Some App Server vendors offer session replication, either via direct inter-server communication or by persisting the session to a database - obviously there are overheads here, so sometimes, for low value sessions we just accept the loss of session in event of failure.

There is an argument that if the session data has high value then it should be persisted by the application, it's actually business data and should be treated as such. Increasingly, NOSQL databases such as Cloudant or MongoDb are used for this. In this case we may think of the HTTP session as a cache, in the knowledge that the session data can be retrieved in the event of error.

So I'd argue that a Shopping Cart may well have considerable value to the business; it represent the customers thoughtful accumulation of things they want to spend money on. So it should be persisted, rather then just kept in the session. Once we decide to persist it, then we find that it leads to other interesting scenarios such as a consolidated experience across many client devices. The customer starts shopping at home on a desktop PC, but completes the purchase online.

So a further principle:

3). Don't over-use the HTTP session just because it's there. Consider the business value of the data and whether it should be persisted.