Child pages
  • Development-WO Session

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


A WOSession provides the encapsulation of all the state that is associated with a user's use of your application. Each WebObjects application has its own subclass of WOSession, which is a significant difference between session tracking in WebObjects and J2EE. In J2EE, HttpSession is not subclassed, and all state is stored as attributes in HttpSession's Map. In WebObjects, sessions are much richer, providing the ability to take advantage of all the benefits of being a full-blown class (typed fields, methods, etc). WOSessions have a timeout time, which by default is configured in the WOApplication configuration. This timeout time determines how long the server will keep the session alive without any active requests. When the session times out, it will be garbage collected.

Accessing the Session

Code Block
Session session = (Session)session();


I still think even this is not a problem in WO5, although it probably is in WO4.5. JRE 1.3.1 is supposed to garbage collect circular references just fine, whether involving an inner class or not. But maybe the JRE doesn't do what it's supposed to? - JonathanRochkind

Session Tracking

The first time a session is requested for a request, WebObjects ensures that all subsequent requests from the same user will use the same WOSession instance. WebObjects achieves this session tracking with one of two techniques: URL rewriting, cookies, or query strings.


Lastly, you can pass a query string attribute named "wosid" that contains the session ID. This is often used when calling DirectActions that need access to the user's session.

Performance Implications

Session creation and persistence must be carefully monitored in large deployments due to the memory usage required to keep the session alive. It is generally recommended to minimize session creation whenever possible. When using "normal" WebObjects techniques, this can be difficult. The default behavior of WOHyperlink, for instance, when calling an action on your WOComponents is to cause sessions to be generated. The typical method for avoiding session creation is to implement your application using DirectActions. DirectActions do not require a page cache to be created for page state preservation, and thus can be used in a completely stateless way. The downside of using only DirectActions is that you lose the benefits of a more stateful approach. For instance, when using DirectActions only, you will find that you have to manually wire up your state objects by interpreting query string variables.


Adjusting your session timeout can have a large impact on performance. The longer a session timeout is, the longer the session will consume memory. Under heavy load, "dead" sessions can build up, so the timeout time should be tuned to be as low as possible without negatively affecting your user's experience with your application.

Hanging Sessions

There are certain cases in WebObjects where thrown exceptions can cause a session to not be checked back into the WOSessionStore, which will deadlock the session. One of the more common causes of this is an exception thrown from a DirectAction that uses a session. If you use Project Wonder's ERXApplication, ERXSession, etc, it provides a prevention mechanism for this problem. However, if you are using a default WebObjects installation without Project Wonder, you will need to deal with this problem yourself. You should not let your DirectActions throw an exception in this case.

Checking for Existing Session

If you are in a DirectAction method when trying to do this, check the following WOAction method (WOAction is WODirectAction's superclass):