views:

2555

answers:

2

Hi there,

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.

+4  A: 

In general JEE 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.

djna
You are right. I had mistakenly understood that the whole session objects are being saved in the session map and the session map is then being sent to the client where it is stored in the form of cookies or hidden field. Instead it is the session id which is being sent to the client. If I understand correctly, this session id can be used to retrieve the instance of the HttpSession that is storing all the attributes for that particular web session, right? Thank you for pointing out my misunderstanding.
SibzTer
+1  A: 

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?

These two things store data in exactly the same place.

<managed-bean>
  <managed-bean-class>foo.Bar</managed-bean-class>
  <managed-bean-name>bar</managed-bean-name>
  <managed-bean-scope>session</managed-bean-scope>
</managed-bean>

Once referenced in an expression, you can lookup "bar" programmatically via the external context.

FYI: in JSF2, the declaration can be removed and replaced with annotations:

@ManagedBean(name="bar") @SessionScoped
public class Bar {
...
McDowell
Must admit it's about 3 years since I touched JSF. Back then I would just use a session scoped managed bean, pretty much as you show. I didn't consider any alternaticve at the time. I guess one issue might be how to make sure we keep this tidy, don't want to gradually acuumulate lots of session-scoped managed beans. This may be down to carefully chosen bean names.
djna