Java Reference
In-Depth Information
client thread. ( fhb doesn't actually have an option to create new sessions anyway, though a
custom driver written in faban can do so.)
Highly available HTTP session state
If an application server is tested in a highly available (HA) configuration, then you must also
pay attention to how the server replicates the session state data. The application server has
the choice to replicate the entire session state on every request, or to replicate only the data
that has changed. It should come as no surprise that the second option is almost always the
more performant one. Once again, this is a feature that is supported by most application serv-
ers but that is set in a vendor-specific way. Consult the app server documentation regarding
how to replicate on an attribute basis.
However, for this solution to work, developers must follow guidelines about how session
state is handled. In particular, the application server cannot keep track of changes to objects
that are already stored in the session. If an object is retrieved from a session and then
changed, the setAttribute() method must be called to let the application server know that
the value of the object has changed:
HttpSession session = request . getSession ( true
true );
ArrayList < StockPriceHistory > al =
( ArrayList < StockPriceHistory >) session . getAttribute ( "saveHistory" );
al . add (... some data ...);
session . setAttribute ( "saveHistory" , al );
That final call to setAttribute() is not required in a single (nonreplicated) server: the array
list is already in the session state. If that call is omitted and all future requests for this session
return to this server, everything will work correctly.
If that call is omitted, the session is replicated to a backup server, and a request is then pro-
cessed by the backup server, the application may find that the data in the array list has not
been changed. This is because the application server “optimized” its session state handling
by copying only changed data to the backup server. Absent a call to the setAttribute()
method, the application server had no idea that the array list was changed, and so did not rep-
licate it again after the above code was executed.
This is a somewhat murky area of the Java EE specification. The spec does not mandate that
the setAttribute() method be called in this case, but that convention is used by virtually
every Java EE application server that supports high availability. For some application serv-
ers, that is the only way session replication works. Others allow you to configure how data is
Search WWH ::




Custom Search