Design question - Persistent data in a webapp session

I am developing a web app using servlets and jsps. I have a question about storing data I need to use across multiple servlets in a login session. When the user logs in, for example, I get the user object from the db and would like to store it somewhere and have the subsequent servlets and jsps use it without having to query开发者_运维知识库 the db again. I know that I have to store the object in a global array but am not able to figure out the best way to do this.

I am thinking of having a static hashmap or some other data structure created at webapp load time and I can use that to store the user object with the sessionID as the key for the hashmap.

Is there a better way? Any help is appreciated.

Thanks, - Vas

You don't need to manage the sessions yourself. The servletcontainer will do it for you transparently in flavor of HttpSession. You normally use HttpSession#setAttribute() to store an object in the session scope and HttpSession#getAttribute() to get an object from the session scope. You can use HttpServletRequest#getSession() to get hold of a reference to the HttpSession.

E.g. in the login servlet:

User user = userDAO.find(username, password);
if (user != null) {
    request.getSession().setAttribute("user", user);
} else {
    // Show error?
}

You can get it back later in any servlet or filter in the same session by

User user = (User) request.getSession().getAttribute("user");
if (user != null) {
    // User is logged in.
} else {
    // User is not logged in!
}

You can even access it by EL in JSP:

<p>Welcome, ${user.username}!

(assuming that there's a Javabean getUsername() method)

There is a way to do this and it's defined in the servlet spec. You can get hold of the HttpSession object and add objects as "attributes".

Take a peek at the API here: http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html

Depending on your needs and implementation, you can also consider following options:

• making user object serializable and storing in session itself; in this case you must assure that subsequent changes to user object are propagated to the objected stored in session or DB (depending which will change)
• storing only user ID in session and implement caching in your DAO/repository so no real DB query will be invoked if not necessary; if you are using Hibernate or some other ORM you might have this feature out of the box; this seems the least invasive as modifications on user object will be synchronized with application state and DB if properly handled by persistence layer

There are probably many more option out there.

We are constructing a social network like livemocha.com and we recommend you put the minimum possible in the session.

Storing only user ID in the session it's enough, and certainly, you don't need to assure that subsequent changes to the user object are propagated to the object stored in the session or DB (depending on which one will change). ;-)