Saving data to session in JSF

£可爱£侵袭症+ 提交于 2019-11-28 04:23:47

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.

I'm working on a project of the university with my colleagues, is a web like GoogleImage Labeler. Well, so we have an UserController, with its methods login, logout, etc... and we scope the session like this:

@ManagedBean(name = "userController")
@SessionScoped

Ok, this is what the wizard of NetBeans creates for you.

Our way of creating and managing the session is:

At the register method (in which we use the attributes of the form in the XHTML...) we persist the user in the DB and then we add the values in the session:

FacesContext context = FacesContext.getCurrentInstance();
context.getExternalContext().getSessionMap().put("user", current);

Where "current" is an User (The logged user, of course). We have the same at the login method.

At the logout method we have:

FacesContext.getCurrentInstance().getExternalContext().invalidateSession();

I hope this helps you.

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 {
...
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!