Fog Creek Software
Discussion Board




Persisting J2EE Web App State

I'm looking for thoughts based upon experience of how best to persist the state of a browser-based application in J2EE. The sort of scenario I'm thinking about is taking the user back to the screen they were viewing when they last logged on, that sort of thing. Would this be a job for an LDAP-compliant directory service?

John Topley
Thursday, March 20, 2003

Are cookies an option?

Walter Rumsby
Thursday, March 20, 2003

Probably but would only want to store the bare minimum of information in a cookie, such as a user ID.

John Topley
Thursday, March 20, 2003

If they had to log in first, you could store it server side.

Mark
Thursday, March 20, 2003

Where? Er, the database?

Duncan Smart
Thursday, March 20, 2003

You could do it in LDAP but this is not a preferred use for such a directory.  In general you want to use LDAP for user info which tends not to change over time.  The one example you give would change every session.

Erik Lickerman
Thursday, March 20, 2003

Every JSP Servlet ... has a session object  (a hashmap)store the relevant info there!

Daniel Shchyokin
Thursday, March 20, 2003

meant to say JSP/Servlet

Daniel Shchyokin
Thursday, March 20, 2003

Also look at struts

Daniel Shchyokin
Thursday, March 20, 2003

A session object is no good, as it goes away when the session is over.  LDAP is a poor choice, see above, and cookies are really useful only for very small snippets of data.

My suggestion would be to make an object that with properties that hold all the info about the browser state, and write a save method for that object that persists the properties.  A static retrieve method could regenerate the object from the storage layer based on a user id.  This abstracts the details of the persistance, giving you more flexibility.

Three possible ways of persisting the data in Java:

-- create a table in a database with 1 field for each property, keyed by the user id

-- add a BLOB field to the user table in the database, and serialize the entire object to a byte array and store that byte array in the BLOB field for the user's record

-- serialize the object to a file and write it to disk with a filename based on the user id

The first method works well for small amounts of data for many users.  The last method works better for large amounts of data for a small number of users. 

Will
Thursday, March 20, 2003

Try this, give everyone a session id, have an object implement serializable and write session out to disk.

Upon session recovery get session id from cookie, read in session

Daniel Shchyokin
Saturday, March 22, 2003

oops didn't read your post will, yep method three sounds good,

the problem with databases, besides being slower than a local file system for this kind of thing, is that the session properties may change.

The scary part with method 3 is be sure there is a reliable way to tell when sessions are done (users may not always touch the "logout" link

Daniel Shchyokin
Saturday, March 22, 2003

Good point-- you can't depend on logout.  But there's several ways to get around this. 

If you're working with the Servlet 2.3 API, you can have the object implement HttpSessionBindingListener.  Store the object in the session, and when the session times out the valueUnbound method will be called (at which point you can serialize it to disk).

Will
Sunday, March 23, 2003

*  Recent Topics

*  Fog Creek Home