web server - Borland Technical Publications

Using HTTP sessions
For example, you can change state without calling setAttribute () as depicted in the
following code example:
Object myState = session.getAttribute("myState");
Note
// Modify mystate here and do not call setAttribute ()
Your configuration file, server.xml, will have the following code snippet:
where xxx is the time interval in seconds that you want the session data to be stored.
For more information about the server.xml file, go to Chapter 5, “Web server to web
container connectivity.”
When using the Automatic implementation, you need to consider the following
limitations:
1 If the web container goes down between two save intervals, the latest changes are
not visible for the next web container instance. This is an important concern when
defining the time interval value for the heartbeat.
2 The data is saved at the specified time interval no matter if the data is changed or
not. This can be wasteful if a session frequently does not change and the defined
time interval value is set too low.
Using HTTP sessions
The HyperText Transfer Protocol (HTTP) is a stateless protocol. In the client/server
paradigm, it means that all client requests that the Apache web server receives are
viewed as independent transactions. There is no relationship between each client
request. This is a typical stateless connection between the client and the server.
However, there are times when the client deems it necessary to have a session
concept for transaction completeness. A session concept typically means having a
stateful interaction between the client and server. An example of the session concept is
shopping online with an interactive shopping cart. Every time you add a new item into
your shopping cart, you expect to see that new item added to a list of previously added
items. HTTP is not usually regarded for handling client request in a stateful manner.
But it can.
BES supports the HTTP sessions through two methods of implementations:
■
Cookies: The web server send a cookie to identify a session. The web browser
keeps sending back the same cookie with future requests. This cookie helps the
server-side components to determine how to handle the transaction for a given
session.
■
URL rewriting: The URL that the user clicks on is dynamically rewritten to have
session information.
Chapter 7: Clustering web components 65