Table of Contents Previous Section

State in the Server

Storing state in memory on the application server is WebObjects default behavior. As you can see from the SessionStores example, the server session store object is accessible from the WOSessionStore class:

id sessionStore = [WOSessionStore serverSessionStore];

[[self application] setSessionStore:sessionStore];

In later sections, we'll look at the principal ways of controlling the amount of memory that this state storage mechanism consumes:

• Setting session timeouts (see "Managing Session Resources")
  

• Setting the size of the page cache (see "Adjusting the Page Cache Size")
  

• Page uniquing by implement pageWithName: in the session object (see "pageWithName: and Page Caching")
  

One consequence of storing state in memory should be emphasized: Once state for a session is established in a particular application instance, all subsequent requests in that session must return to that instance. WebObjects handles this automatically by including the application instance number in the URL, as illustrated in Figure 2: "Parts of a WebObjects URL".

However, at a popular web site it may be desirable to have multiple application instances (perhaps running on different physical machines) service incoming requests. As long as the application is stateless---or the state is stored outside the application (as with any of the other techniques described here)---the WebObjects adaptor can route requests to any available application. However, if session state is stored in memory, a request must return to the application that stores that state. (See Serving WebObjects for more information about running multiple application instances.)

Table of Contents Next Section