Comparison of Storage Options

These options are discussed in more detail in later sections, but seeing an overall comparison might save you time in deciding which options to explore.

Table 1: Comparing Storage Schemes

feature State in server State in page State in cookies Custom storage

Simplicity Simplest approach; WebObject's default. Relatively simple, but can involve design changes to application. Relatively simple. More complex.

Security Secure since state is on server and accessed by encrypted session IDs. Since data is passed to client, opens possibility that data could be modified by user. Since data is passed to client, opens possibility that data could be modified by user. If stored on server, can be as secure or more secure than state-in-server.

Scalability Can consume lots of memory. Also, can't use round-robin request handling once state is established in a particular application instance. More scalable since any application instance can handle a request (because state is bundled with each request). Applications don't grow when new sessions are added. Not very scalable. Cookie specification limits capacity to 4K bytes per cookie, but some browsers have further limitations. Depends on design of storage. If filesystem or database used for storage, can scale to accommodate almost any need.

Reliability Least reliable since if the server crashes, state is lost. More reliable since a server crash doesn't affect state stored on client. More reliable since a server crash doesn't affect state stored on client. Can be extremely reliable if state is stored in server file system or database.

Other Performance can suffer if lots of data is passed back and forth between client and server. State can become out of sync, especially when using frames. Client can refuse to accept cookies.

feature	State in server	State in page	State in cookies	Custom storage
Simplicity	Simplest approach; WebObject's default.	Relatively simple, but can involve design changes to application.	Relatively simple.	More complex.
Security	Secure since state is on server and accessed by encrypted session IDs.	Since data is passed to client, opens possibility that data could be modified by user.	Since data is passed to client, opens possibility that data could be modified by user.	If stored on server, can be as secure or more secure than state-in-server.
Scalability	Can consume lots of memory. Also, can't use round-robin request handling once state is established in a particular application instance.	More scalable since any application instance can handle a request (because state is bundled with each request). Applications don't grow when new sessions are added.	Not very scalable. Cookie specification limits capacity to 4K bytes per cookie, but some browsers have further limitations.	Depends on design of storage. If filesystem or database used for storage, can scale to accommodate almost any need.
Reliability	Least reliable since if the server crashes, state is lost.	More reliable since a server crash doesn't affect state stored on client.	More reliable since a server crash doesn't affect state stored on client.	Can be extremely reliable if state is stored in server file system or database.
Other		Performance can suffer if lots of data is passed back and forth between client and server. State can become out of sync, especially when using frames.	Client can refuse to accept cookies.

If you know you want to use WebObjects' default server-side storage mechanism, read the "State in the Server" section below and then you can skip to "Controlling Session State" for information about managing the memory requirements of your application. If you want to examine the other storage options in more detail, continue with "A Closer Look at Storage Strategies".

Table of Contents Next Section