Table of Contents 
Previous Section
A Closer Look at Storage Strategies
To compare and further understand state-storage options, look at the SessionStores sample application. This application presents the user with a choice of storage strategies:
Once a storage strategy has been chosen, the application plays a guessing game with the user:
As you can see, the application keeps track of a user's previous guesses within a session-these guesses are part of the state that must be stored from cycle to cycle.
The SessionStores example was designed to illustrate WebObjects' support for various state storage strategies, so it lets you switch between strategies while the application is running. This is not a design you should emulate in your applications-changing storage strategies midsession can cause errors. For example, imagine an application that stores state in the page during the first half of a session and stores state in cookies for the second. Now, suppose that the user backtracks from a page in the second half to one in the first and resubmits the page. The application's strategy and the actual storage mechanism won't match, and state will be lost.
In a normal WebObjects application, you should set the session storage mechanism as early as possible, usually in the application object's initialization method. You set the mechanism by sending the application object a setSessionStore: message. This method takes a WOSessionStore (or SessionStore in Java) object as an argument. WOSessionStore declares these methods to create specific types of session stores:
- serverSessionStore
- pageSessionStore
- cookieSessionStoreWithDistributionDomain:secure:
Table of Contents 
Next Section