Apple WebObjects 3.5 - Manual (Page 121)

State Storage Strategies
121
• In cookies . State is embedded in name-value pairs (“cookies”) in the
HTTP header and passed between the client and server. Like “state-
in-the-page,” cookies store state on the client.
• In custom stores . State is stored using a mechanism of your own design.
By default, WebObjects uses the first approach, storing state on the server.
To determine whether you should use this default approach or try one of the
other state-storage solutions, read the next sections, “Comparison of
Storage Options” and “A Closer Look at Storage Strategies.” If you decide
to use one of the other state-storage solutions, you may have to set up
custom objects so that they can be archived. To learn more about this issue,
read “Storing State for Custom Objects” (page 131).
You may find you need to control the amount of state that is stored. The
sections “Controlling Session State” (page 133) and “Controlling
Component State” (page 135) tell you how to do so.
Comparison of Storage Options
The following table summarizes the pros and cons of each of the state
storage options. These options are discussed in more detail in the next
section, “A Closer Look at Storage Strategies,” but seeing an overall
comparison might save you time in deciding which options to explore.
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
load balancing 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 file
system 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.